The other day, the application team came to me to diagnosis an old issue with their application. Its application that launches java programs, each spawning a java.exe process. They found that after spawning 50+ processes, the next attempt will error with “Not enough storage is available to complete this operation.”
Now if you do a search on google, the first thing that you will find is a description of IRPStackSize registry key. However, what is odd about this problem is that the eventlog is clean. There are no events related to IRPStackSize issues. Snce most articles regarding “not enough storage” points to IRPStackSize, I decided to make the changes to the server and see if it helps. However, even after setting the value up to 30, there was hardly any improvements in the number of additional java.exe processes that can be spawned. So this eliminates the IRPStack issue.
However, I noticed that as more processes are launch, the commit charge used seem to increase to > 90%. So my second thought was to increase the RAM and page file size. The server (its a vmware guest) was a 1GB with about 3GB page file, so I increased it to 2GB with 4 GB page file. Still, this did not help, but the commit charge did fall to around 60% used.
Well, I did see some articles referring to “out of memory” when launching too many programs due to desktop heap size, but kept that in the background because the application log did not complain about “out of memory”. However, after talking to Microsoft, they suggested that it could be due to desktop heap size and suggested that we increase the non-interactive value from 512 to 1024 (Windows 2003 32-bit).
Sure enough, after increasing the value from 512 to 1024, we could launch up to 90+ jave.exe process before the commit charge was hitting its limits.