The fork function failed. Too many processes already exist. on K360 Server

[mahesu]

I have K360 server, works on HP-UX 11.00, SAP R/3.
Freequently I am getting the message
"The fork function failed. Too many processes already exist."Assertion failed:!(tgets(hardware Addr,(STERLEN - 1),fstream ==NULL), file snluic, line1210

Every time I need to reboot the server.

Is there any work around for this...?

Mahesu.V

[Bill Hassell]

Your kernel needs a lot of parameters changed as it sounds as if you are using the kernel shipped with the system. While you could change the kernel parameter nfile, you would soon have tyo change nproc and many others.

Start with sam and go to Kernel Configuration -> Configurable Parameters, then change the macro value maxusers--triple it for now. The kernel requires fixed values for most of it's tables so you must monitor many of the values and change them before they are overrun. The maxusers value will adjust several parameters at the same time.

Another value is maxuprc which may need an increase if you have many users logging in under the same user ID.

[John Bolene]

As Bill said, maxuprc is a good one to up, but also up nproc.

Good values for maxuprc is 200, nproc is 1024.

You can use Glance system tables report to check what is currently being used and up those. Start with a 50% increase if the above 200 and 1024 are not enough.

You may also need to bump nfile to 3000 since that will be the next thing to do.

[David Lieberman_1]

Mahesu,

It is generally best to modify a "base" parameter and only tweak formulas or override formula-derived values when absolutely necessary. This prevents kernel parameters from getting too far "out of balance" with each other.

The default values of nproc, ncallout, ninode, and nfile (et.al.) are defined in terms of maxusers. Thus, by modifying maxusers, you may not have to tweak the other parms individually (much). Keeping maxusers "reasonably" small helps keep the size of the kernel down and may result in a more efficient kernel. Of course it should be large enough that you don't get "table full" errors...

Since Bill mentioned that you might have the default kernel, the Dynamic Buffer Cache is usually set way too high from the factory. This doesn't affect the symptom that you mentioned, but setting it properly will likely free a significant amount of memory. You may wish to check it.

As a start, I use the following values:

(the values listed by Bill and John are directly related to, and should correct, your problem)

maxuprc: 200
maxusers: 124
maxfiles: 200
max_dbc_pct: (pct. that gives ~300MB cache)
ninode: <=15000 (typically ~3000 - smaller is often better. <=4000 on 10.20 to avoid a spinlock contention problem)
maxssiz: 79MB

Use extracts from MeasureWare to keep an eye on the tables. Although glance and gpm provide semi-realtime table information and are certainly useful, you don't really have historical visibility. PerfView (an add-on product) may be helpful.

[Manel Ventura]

Hi,

I think you should revise the configuration of SAP and also of your database. You probably have the memory parameters very high and the system starts up with great difficulty. In the moment that some few users consume a lot of memory in SAP, the system doesn't have enough memory neither to create a new process.

Check the available space in the swap (swapinfo - t) when it happens.

Also, when it happens, is not necessary that you restart the machine. From SAP, execute the transaction SM50. Locate you in a free DialogWorkProcess (remember their PID) and execute the menu option: Process--> Restart after error--> No. Then, at operating system level, kill the process (kill ?9 ?PID?). This will liberate enough memory (so that you can examine what is happening).

[Magdi KAMAL]

Hi,

2 Issues :

1. Your kernel parameters are low.
2. Some application are creating ZOMBIES process by miss programming the protokol of how to avoid zombies.


have a look on how to avoid ZOBIES in my following thread :

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xa26e87dc4d7dd5118ff00090279cd0f9,00.html

Magdi

[Sridhar Bhaskarla]

Some hints.

Whenever you get this message, try doing this

sar -v 2 20.

Note the value in proc-sz. If the value used it almost equal to the value set, then you need to increase nproc. Otherwise maxuprc.

Your ps -ef|wc -l should give almost the same value that you see in sar -v command.

Now increase your nproc by 30% to whatever you have now.

If your ps -ef|wc -l produced 2000, Increase nproc to around 2500.

Keep a watch on this using sar -v.

-Sri

[Ajitkumar Rane]

Hi Maheshu,

Apart from the kernel parameters information mentioned by the forum members, I would suggest you should also take a look at the defunct process as said by Kamal. Sometimes the system might be having too many zombies/defunct process generated which will cause this problem. check "ps -ef | grep defunct". Most of the time the basic kernel works fine, unless and until your environment is large.

Goodluck.