FX and TS and not mutually exclusive. I find there are compelling reasons for mixing these with Oracle. OLTP client processes tend to do quite well in TS, since well-behaved OLTP queries tend to stay at TS 59 while compute- intensive queries and utility operations drift to lower priorities. That's usually a Good Thing. Since Oracle does not tell Solaris that the background processes are special, it makes a whole lot of sense to run these in FX - especially LGWR - to make sure they are never punished by TS for being very busy!
FX can also be used to prevent a collection of homogeneous processes from mutually interrupting each other. That can happen when they are run in TS and develop a range of priorities. One can always use 'ps -e -o pid,class,pri,args' to sample process priorities and see if they make sense. If many similar processes are priority-preempting each other, FX is one possible remedy. One can also explorer using dispadmin to change the TS dispatch parameters. In general, use 'prstat -m' to study the pattern of ICX versus VCX for various processes - independent of what scheduler class they are in. (It's somewhat of an art to interpret that data. It would help to see Solaris involuntary context switches decomposed to observe how much is due to time quantum expiration versus preemption.) If there is a significant rate of avoidable ICX, that can translate into general inefficiency from avoidable migrations and frivolous cache churning. I just found that Google(involuntary context switches decomposed solaris) finds some good references on this. The broader discussion of managing QoS with competing workloads also includes FSS. It would make sense to mix FX with FSS from my perspective, but it's currently a controversial topic. Simply put, it makes sense to hand out some "unfair shares" first, such as for critical background process - before handing out the rest in a "fair" manner. Indeed, there is no fairness involved in the cycles used by interrupt processing, the kernel, or STREAMS - and various time-critical processes already have preferential RT or SYS scheduling - but mixing FX with FSS always seem to start a debate. At any rate, optimizing for peak steady-state throughput is not what most users actually want to do. What most users want is simply for important things to happen ahead of relatively unimportant things, so that overall QoS is managed between various classes of work. There are many options for advancing in that direction; far beyond just picking a scheduling class. Indeed, I think it's a truly fascinating frontier. Regards, -- Bob [EMAIL PROTECTED] wrote: > Hi all, > > I have encountered mixed opinions regarding which scheduler is > better for OLTP databases (mainly: Oracle). Solaris Internals site > http://www.solarisinternals.com/wiki/index.php/FX_For_Databases > http://www.solarisinternals.com/wiki/index.php/Application_Specific_Tuning#Tuning_Recommendations > recommends using FX for databases. > However http://blogs.sun.com/travi/entry/database_scaling_on_sun_fire > says: "We also tried different scheduling classes. FX as well as RT > but noticed that at even at high throughput the default TS scheduling > class performs the best.". > > While the former says in general the latter is strictly for CMT cpu. > But I don't belive (am I wrong ?) that it depends on cpu type. > Can anybody share his/her experience with changing scheduler for > OLTP (Oracle ?) databases ? > > Regards > przemol > > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org