Re: Reduce Solaris context switches possible?

"Brian" <brian.bream_at_attbi.com> wrote in message news:hmz79.183291$uj.259471_at_rwcrnsc51.ops.asp.att.net...
> "Alan Coopersmith" <alanc_at_CSUA.Berkeley.EDU> wrote in message
> news:ajlsq0$k8a$1_at_agate.berkeley.edu...
>
> > It's much more complicated than that - you can edit the scheduling class
> > dispatch table, which includes the time slice for each priority level
> > and the bits that control what priority level processes go to when they
> > are put back into the queues. This is done with dispadmin, but I
> > wouldn't recommend doing it without learning a whole lot about how the
> > Solaris scheduler works, via a kernel/tuning class or book.
> >
> > --
> > ________________________________________________________________________
> > Alan Coopersmith alanc_at_alum.calberkeley.org
> > http://soar.Berkeley.EDU/~alanc/ aka: Alan.Coopersmith@Sun.COM
> > Working for, but definitely not speaking for, Sun Microsystems, Inc.
>
> This "guy" had probably heard this in a SA-400 course. The dialog goes
> something like this:
>
> The kernel dispatcher makes adjustments to thread priorities based on how
> they are interacting with the system. A thread that is using up all of
it's
> time quantum (CPU hog) will be assigned a longer time quantum the next
time
> it is assigned to a processor, but at the expense of having it's priority
> lowered (by default 10 lower than it was when it exceeded it's time
> quantum). A thread that has been sleeping (blocking waiting on I/O for
> example) will have it's priority increased but at the expense of having
it's
> time quantum lowered.
>
> So if you know that you have a CPU bound application, you can use
dispadmin
> to alter this dispatch table to get the thread back on the CPU quicker.
The
> hope is that the thread gets back on the CPU before the data in the ecache
> or perhaps even the L1$ is overwritten by another thread. Some people
find
> the default degradation of 10 for a CPU bound thread to be too high moving
> it quickly down the run queue and ensuring that the L1$ and L2$ will need
to
> be reloaded.
>
> The SA-400 course book explains how to create a hybrid dispatch table
using
> the current values and earlier versions of Solaris where the dispatch
table
> was tuned for batch processing by Sun Microsystems
>
> Any changes made with dispadmin will not survive a reboot. One must save
> the modified dispatch table and then call for it in a run control script.
>
> That said..... I agree with all the previous advice. Get Cockcroft's
book,
> I also recommend McDougals Solaris Internals book, good info regarding the
> dispatch table. Attend a performance management course, and look for
other
> areas first, tune the I/O, UFS out of the box needs quite a bit of
tweaking
> to run better. Look at memory and tune there first. After all of this,
> then, maybe, adjust the kernel dispatcher. Just remember that unless you
> save the table and call dispadmin via a RC script, all your modifications
> are lost after a reboot.
>
> Brian
>

I despair.

Here we are again, dancing on the head of a pin looking for a 2% improvement by tuning the OS. I just hope we've looked at the database design, and at the SQL, before we've resorted to this.

Paul Received on Sun Aug 18 2002 - 14:51:22 CDT