High SysUtil than User Util

[Sreekanth Makam_1]

Hi Folks,

My application is doing high system util that is 80% than user util(15%).
As a first step I used the tusc for that process. I saw, there are many many system calls and hence the sysUtil.
My question is,
Most of the time my process is doing ksleep(U can see in tusc output attached). What is this ksleep?
Why this is taking too much of CPU?
How this is differ from sleep?

Please check the tusc output and can anybody explain what it says..I am new to tusc..

Thanks in Advance,
Sree

[Steven E. Protter]

If system is using 80% and user(the application) is using 15% a few causes come to mind.

1) A poorly written application is doing too many system calls or other unfriendly things triggering the system resource useage.

2) The system is swapping badly, or otherwise overloading system resources.

The key to figuring out the trouble is to see what processes are running.

I've attached a sar based data collection script that should help us figure out what process is doing what. It can also detect disk i/o and wait issues.

Attached:

SEP

[Bill Hassell]

ksleep is part of the sleep routines and is used in multi-threaded processes. It is taking the amount of CPU time that the programmer wrote. It is taking a lot of CPU time because it is being called a lot. But from your tusc output, there are far more reads and lseeks than any other system calls. When an application uses massive amounts of kernel time, there is always a question about the design of the program. There is nothing you can do about this in HP-UX. You'll have to call Cognos to discuss the excesively high system overhead. There's always a possibility that you are not up to date on thread patches and/or kernel patches.

[rick jones]

You might also take a look at the relative counts of system calls - either with the option in tusc, or via the "l" screen in glance.

ksleep is part of the thread mutext/condition variable aquisition path. It can indicate non-trivial mutex contention in an application if there are also many sched_yield() calls (modulo someone "tuning" the spin counts for mutexes).

Some of the paramters to the ksleep call will say if they are for a mutex or a condition variable, and will give the address of the same. If they are all for the same address, it suggests contention. If they are all for different addresses, it suggests perhaps overly fine-grained locking. Those are both in basic broad handwaving terms, exceptions may apply.

The usual song and dance about being on the latest pthreads patches would apply, and then as Bill has suggested, getting in touch with the application vendor.

You might be able to get further/kernel profile information with prospect if you are on PA-RISC, or caliper if you are on Itanium. I believe that http://www.hp.com/go/prospect and http://www.hp.com/go/caliper may get you to those tools.