Re: 10046, Unaccounted for Time, Aix 5.3 -- How to Determine Process Pre-Emption

From: Kerry Osborne <kerry.osborne_at_enkitec.com>
Date: Wed, 2 Dec 2009 20:47:20 -0600
Message-Id: <CEBCE18D-5751-48CE-B0C0-1F1AC1AE2AAF_at_enkitec.com>



I'm not too familiar with aix but Solaris has several scheduling algorithms (Real Time, Fair Share, Time Share, etc...) These have different ranges of priorities. Do a man on ps. It probably has options to show priority and scheduling class (i.e. the algorithm). Mixing different algorithms in a single VM can cause problems.

Here's the command in solaris that shows that info:

ps -ef -o user,pid,project,class,zone,pset,pri,nlwp,psr,time,args

As already mentioned, vmstats/sar should also give you a good clue as to whether processes are struggling to get on the CPU.

There is a great Solris Internals book that describes all the scheduling algorithms among other things. I presume there is a similar reference for AIX. Also, I'd recommend Millsap's book for a better understanding of how/why unaccounted for time occurs.

Kerry Osborne
Enkitec
blog: kerryosborne.oracle-guy.com

On Dec 2, 2009, at 2:13 PM, Larry G. Elkins wrote:

> Listers,
>
> SA's asking for assistance on how to tell if a process is being
> impacted and
> to what degree by processor pre-emption. AIX 5.3. Asked in the
> context of
> trouble-shooting some significant unaccounted for time issues in
> 10046 trace
> files (e.g. 14 of 16 seconds unaccounted for vendor process, 300 of
> 700
> seconds unaccounted for vendor batch job, etc). SA's have "ruled out"
> overhead of writing the trace file so now looking at the pre-emption
> aspect.
> A bit out of my league, and I find plenty of approaches in IBM docs,
> and
> from people on this list (but geared more towards Solaris and other
> flavors,
> not Aix). 9.2.0.8 EE and 10.2.0.4 EE, "static" and dynamic LPAR's,
> seen on
> various boxes and databases.
>
> Larry G. Elkins
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Dec 02 2009 - 20:47:20 CST

Original text of this message