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

Reply via email to