Process Fork Problem on HP-UX

[Ankit Grover]

Hi experts,
We are using HP-UX B.11.23 ia64, 4 CPU box. I am facing the following error while trying to execute any script:
ksh: cannot fork: too many processes

On checking in "top -h", I observed that the processes count was going to a max of 4096 which comes to be 2^10 processes per processor (it seems it is the limit, plz correct me if I am wrong). Out of these around 4000 were sleeping and CPU was 97% idle.

Last time when it happened we had to restart the server. Luckily this time, the processes count automatically got reduced.

Can anyone suggest what can be done from our side?

[Duncan Edmonstone]

Ankit,

man kctune

you need to adjust the nproc kernel parameter

e.g.

kctune nproc=8192

you may require a reboot after this (some parm changes do)

Are all 4000 odd processes in the proc table valid? or is something spawining too many procs?

HTH

Duncan

[Ankit Grover]

Hi Duncan,

KCTUNE is currently displaying:
[root]/home/scripts#kctune nproc
Tunable Value Expression Changes
nproc 4096 4096 Immed

I don't want to increase its value since normally the count is in the range of 600-700 and most of them are sleeping.
I am not able to trace what happened at that particular time which increased the processes to 4096 level.

Also, can you tell me how to check the validity of processes in the proc table.

Thanks.
Ankit

[Ankit Grover]

While surfing I have found that my problem can be resolved if I tune the parameter related to max no of forked processes per login.
Can some expert help me on this?

[Bill Hassell · Accepted solution]

Too many processes can be the error message from the kernel's process table size (set by nproc) or by the maximum number of processes owned by a single user (which is maxuprc). The limit has nothing to do with the number of processors or CPU usage.

It is common for some application vendors to recommend large values for maxuprc, but not recommended until it can be shown that such a large number makes sense. A simple (but defective) script can start thousands of processes in a few seconds so maxuprc makes sense to prevent a runaway script or program from using every process table entry. In your case, having nproc=maxuprc is a very bad setting. Always set maxuprc to at least 100 less than nproc to prevent a system lockout condition where not even root can login.

To find the process counts by user:

UNIX95=1 ps -e -o ruser=|sort|uniq -c

Note that root is not restricted by maxuprc.

[Steven E. Protter]

Shalom,

It would seem your analysis is flawed. I agree that nproc needs to be increased to solve this problem.

SEP

[Ankit Grover]

Setting maxuprc to a lower value seems to have solved the problem.
Thanks for the help.