[CentOS] kernel load 40-50%?

[Peter Arremann]

On Saturday 26 November 2005 13:01, Greg Knaddison wrote:
> On 11/26/05, Rob <four4 at naims.co.uk> wrote:
> > On Fri, 2005-11-25 at 19:21 -0500, Peter Arremann wrote:
> > > some from of processing in user mode. Then use strace -p <pid> to check
> > > the
> >
> > Just tried this on a gnome-terminal process and locked up X. What did I
> > do wrong?
>
> That's probably a hardware problem.
I agree - if this happens, its likely hardware. What kind of hardware 
configuration do you have? Have you changed anything lately? Have you had 
this issue for a longer time or did it suddenly appear? What kind of 
applications do you run on that system? 

> Why not just use top?
Because top does not display the cause for the time spent in kernel mode. 

Compile the following piece of code:

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>


int main () {
        struct stat buf;
        while (1) {
                stat ("/etc/passwd", &buf);
                //sync();
        }
}

You will see that your system spends near 100% of its time in kernel mode. Top 
will show the same. Start some other apps, do other things, the display will 
never change. 

Then uncomment the line with the sync and put the comment in front of stat. 
Recompile, and re run. Again, you'll see a high percentage of kernel time, 
and the program will show that it is the cause. 
Now, again start using other software. The time spent writing their own data 
to disk is then added to the other process' timing and if you do enough IO, 
you will see the process that issues the sync only having a few percent cpu 
time. A simple "dd if=/dev/zero of=/dev/null" should be higher on your list 
than 

There are many other system calls that for one reason or another are not 
reported correctly by top. Top is a very good starting point but in a busy 
system it is fairly unreliable. 
Strace also tells you what kind of work the process is doing and if you have 
some programming experience that often points you directly at the problem.

Peter.