output of "sar -c" command

[LucianoCarvalho]

Hi guys!
Could anyone explain me what it means when fork/s has a high number in the sar -c output?
And what could be done to decrease this value if it is necessary.
thanks

[A. Clay Stephenson]

It means that your box is spawning many new processes. This might be perfectly normal or it might be the result of rather dumb scripting and/or programming.

For example,

find / -exec echo {} \;

would spawn a new echo process for each file found on the entire system.

You need to examine your box using Glance, top, ps -ef and note if many processes are being spawned and terminating very quickly.

[Chris Wilshaw]

It means that the processes on your system are creating a high number of child processes. This in itself isn't neccessarily a problem as long as your processor can handle the transactions effectively, and also as long as the processes are being closed down quickly too.

Check on sar -v for the number of processes (proc-sz column). This tells you the current number of processes and the maximum available on the system. If this is approaching its limit, increase the value of nproc in the kernel.

[Brian Bergstrand]

If exec/s is pretty close to fork/s then you have a bunch of new processes being created. If exec/s is quite a bit lower, then you have some processes creating a bunch of children.

A fork followed by an exec loads a new image into a new process, a fork by itself loads the current image into a new process.

HTH.

[James R. Ferguson]

Hi:

Clay's pointer to the abuse of 'find' is elegantly demonstrated in 'sar' data when a user uses '-exec' to spawn a process for every argument produced by 'find'. The lesson is to pipe to 'xargs' to spawn a "batch" of arguments to a single task:

Run 'sar -c' and observe for yourself the difference between the very (stupid) brutal :

# find / -exec ls -l {} \;

...versus...

# find / |xargs -L500 ls -l

See the man pages for 'xargs' for more information, but teach your users the benefit!

Regards!

...JRF...

[LucianoCarvalho]

Just one doubt.

If the fork/s has a high number, this could cause bad performance? And what is affected, the CPU with more load?
thanks

[Brian Bergstrand]

Forks are pretty expensive in terms of kernel/io time, but unless you have thousands occuring every minute, they shouldn't impact performance that much. The scheduler will be working harder, and there will be more resources in use (files, memory, etc), but the impact should be negligible.

Are you seeing any performance problems indications? What is the CPU usage? What is the run load?

[LucianoCarvalho]

Attached is the output of top and sar -c.

[James R. Ferguson · Accepted solution]

Hi:

Your 'sar' and 'top' output don't offer a great amount of information.

I'd run 'glance' with a rapid refresh rate (~5 seconds) and examine at the "process list" screen. Look for processes that are marked "died". You may be able to see a fair number of them and then using their pid and ppid track down the rapid spawning that is occuring. You may find that you have an orphaned process that is running away.

Regards!

...JRF...

[LucianoCarvalho]

I found no processess in glance with the flag "dead".
I'm using glance in character mode.