topic Re: fork problems in Operating System - HP-UX

fork problems

Marcin Kurc — Thu, 07 Feb 2002 12:50:30 GMT

Hi,
I'm running software which produces scratch files. Every time the file size reaches 32768 k I'm getting the following error:
*** Operating System Function -
*** fork() failed : Not enough space (errno=12)

Could anybody tell me what kernel parameter is responsible for this behavior?
thank you

Re: fork problems

Justo Exposito — Thu, 07 Feb 2002 12:54:37 GMT

Hi,

I think that is nproc, if you have glance you can view it. If not there are a evaluation copy in the applications CD.

Regards,

Justo.

Re: fork problems

harry d brown jr — Thu, 07 Feb 2002 12:54:48 GMT

maxdsiz

Post what you have from kmtune

live free or die
harry

Re: fork problems

Marcin Kurc — Thu, 07 Feb 2002 13:02:35 GMT

here is my kmtune output attached

Re: fork problems

James R. Ferguson — Thu, 07 Feb 2002 13:07:39 GMT

Hi Marcin:

It is very likely that you have insufficient swap space. Have a look via:

# swapinfo -tam

Regards!

...JRF...

Re: fork problems

John Palmer — Thu, 07 Feb 2002 13:09:28 GMT

Given the following from 'man fork'...

[ENOMEM] There is insufficient swap space and/or physical memory available in which to create the new process.

(ENOMEM is error 12).

I'm not convinced that a kernel parameter is responsible. Is the application issuing lots of forks?

Regards,
John

Re: fork problems

Marcin Kurc — Thu, 07 Feb 2002 13:15:04 GMT

Thanks everybody,
Jamses, there seems to be enough swap space.
Yes, the application uses a lot of forks. Also the application does not use all the memory. I thought that it might have somthing to do with the kernel limits because of the specific size of the scratch file while it crashes.

Re: fork problems

Rita C Workman — Thu, 07 Feb 2002 13:19:20 GMT

Your parms list is interesting..
Jim mentions looking at swap..I'd add look at how your parms are handling swap.
You have bufpages set to the calc of nbuf*2...nbuf is set to default of 0 (I would have set bufpages to 0 as well, so these could work dynamically to control buffer).
You have swapmem turned off=0 (I would have turned it on, since I like the system to control memory dynamically).

What I'm saying is looking at your parms....it says your trying to set up to control that buffer stuff(now Jim & Clay can do that - I'm not that good...so I let the system handle as much of this as I can set up..)

So what I'm saying is - look at how much swap you have set up...and set up your parms to allow for more dynamic control of cache...
I only looked at this point of view-there were some other things in your parms that caught my eye...but not knowing your system or apps, I felt best to leave those alone.

I haven't finished my coffee-so hope this made some sense.

Rgrds,
Rit

Re: fork problems

Marcin Kurc — Thu, 07 Feb 2002 13:28:05 GMT

Thanks Rita, I'll try it.
This box is optimized for CAD/CAM.
Everything makes sense, except bufpages if nbuf=0 and bufpages=NBUF*2 then bufpages=0
I had 3 coffees this morning :)

Re: fork problems

James R. Ferguson — Thu, 07 Feb 2002 13:29:04 GMT

Hi Marcin:

Please post the output of 'swapinfo -tam'. As Rita noted, you have pseudoswap disabled. This means that you *must* have an equal amount of swap as you do physical memory in order to start a process. This could be very limiting for you!

Regards!

...JRF...

Re: fork problems

Marcin Kurc — Thu, 07 Feb 2002 13:32:10 GMT

Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 1024 61 963 6% 0 - 1 /dev/vg00/lvol2
reserve - 380 -380
total 1024 441 583 43% - 0 -

Also, this box has 1024 megs RAM and it's using around 500 on average.

Re: fork problems

James R. Ferguson — Thu, 07 Feb 2002 13:34:42 GMT

Hi (again) Marcin:

If nbuf=0 and bufpages=0 then you have enabled the dynamic buffer cache, and hence dbc_max_pct and dbc_min_pct operate. Your values for those are quite convervative. The buffer cache speeds file I/O by leaving file's buffer's in memory. I don't think this is a problem here.

Regards!

...JRF...

Re: fork problems

Marcin Kurc — Thu, 07 Feb 2002 13:38:41 GMT

James,
dbc_max_pct and dbc_min_pct values were suggested by tech support (app developers) it didn't do much good anyways.

Re: fork problems

Rita C Workman — Thu, 07 Feb 2002 14:05:08 GMT

Marcin,

First tip...listen but not necessarily comply with a vendor's stmt on what your parms should be.

You need to watch and determine how the system should be tuned....

I agree w/Jim those dbc_max% and dbc_min% are really pinching the penny...

Just a thought...coffee in hand..
Rita

Re: fork problems

oiram — Thu, 07 Feb 2002 14:25:05 GMT

Hi,

Perhaps this is too obvious but have you checked your ulimit values?

Best regards.

Re: fork problems

A. Clay Stephenson — Thu, 07 Feb 2002 14:30:53 GMT

Hi:

I've had quite a bit of experience with CAD/CAM/Analysis packages and many of them do funny/stupid things with the .profile (or more often .cshrc). After looking at this, I'm beginning to suspect that we are overlooking the obvious - Soft limits. I would do a ulimit -a. Also, just so we know for sure, a few ps's to display memory usage would be good along with some swapinfo -a output.

Use this Bill H. variant of ps to determine memory usage:
UNIX95= ps -e -o vsz,ruser,pid,args

If you will post that stuff, I think that this can be nailed down. Of course, Glance would be much better but ...

Good hunting, Clay

Re: fork problems

Marcin Kurc — Thu, 07 Feb 2002 14:39:13 GMT

Here are my ulimit settings
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 81612
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 512

and ps output attached

Re: fork problems

A. Clay Stephenson — Thu, 07 Feb 2002 14:58:31 GMT

HI:

You have a 725MB process running on a 1000MB box. When that forks, you are dogmeat. Your average memory usage of around 50% matters not, it's the peaks that are killing you. You are one of those rare modern cases that need 2-3x swapspace and/or a lot more memory. If you don't have any raw lvol space left, you might add filesystem swap at low priority but you really need more memory.

Re: fork problems

Marcin Kurc — Thu, 07 Feb 2002 15:09:38 GMT

Thanks Clay,
I'll try to add more swap, if that doesn't work then I'll have to steel some memory from those surfing the internet.

Re: fork problems

James R. Ferguson — Thu, 07 Feb 2002 15:11:12 GMT

Hi Marcin:

Since adding additional swapspace (given that you have adequate 'maxswapchunks' based on you 'kmtune' output) doesn't require a reboot, you could do that.

In addition, I think I'd schedule a kernel regeneration and enable pseudoswap (swapmem_on=1). As I alluded in an earlier post, this will allow more processes to start since process space isn't reserved for three fourths of physical memory when psuedoswap is enabled.

The small overhead associated with pseudoswap is probably less important to you than anything else.

Regards!

...JRF...