cpu idle time

[mtmigs]

I am transitioning our data processing center from Unix to Linux. One of the frequently used commands under Unix was sar. I used this to analyze system performance when processing data in batch operations. If the WIO% was high it was bad. The idle% was always zero. Now with Linux (SuSE 10.3) I find the same program processing the same data that the sar command shows over 40% idle time. The WIO is only 5%. Then the nice gets 15%. Our batch processing is dedicated with one user on a server. There is no need to be nice. Why is so much CPU time going to things other than user%, sys% and WIO%?

[Ziplock]

Is the batching using only 1 core of a multi-CPU setup or similar? If you are using 'ps' to get the information, one core could be 20% used, the other 100% and would lead to 40% idle.

[mtmigs]

This is an older computer. There is only one CPU and I do not think it is a multi-core CPU. We have a very similar computer running Unix. That is the computer that shows idle as 0% when running the same batch process.

[Ziplock]

Hi there,

If it makes you more comfortable, you can install sar on the linux box. The package is sysstat and will probably be available under SuSE. This should give you a better picture if they are performing in the same way.

From what I can tell, top/ps gives instantaneous usage, sar gives a picture over time.

[mtmigs]

(you can install sar on the linux box. )

I already have installed sar.

The sar program is where I got the information listed in the first message.

(From what I can tell, top/ps gives instantaneous usage, sar gives a picture over time.)

I understand the difference between top/ps and sar. However, they both report 30% to 40% idle time.

I keep running tests and I keep seeing 30% to 40% idle times even when there is very little disk drive activity. It seems that the system is reserving CPU time for other system users when there are no other system users.

[Ziplock]

I have asked around the office here as we do very similar type of jobs processing images that was moved from Tru64 to Linux. We found that we had the same type of issues, and eventually came to the conclusion that single operations on the dataset were taking less than the measured time increment (ie 1 image took less than 0.1 second to process some of the time) so that the tools did not get a true picture of the processing. This may be an incorrect assumption, but it certainly didn't go twice as fast when we ran 2 As far as we could tell, there is nothing standing in the way of 100% CPU usage on the system should it be required.

I'm sorry I can't help you further! I hope you find an answer!