[comp.unix.wizards] Process Limits

mikei@ctdi.UUCP (Mike Israel) (12/07/89)

I am having a problem which I am hoping a wizard can shed some light on.

I am running AT&T Unix SYSV on an AT&T 386WGS with 16 meg of memory.  The
system is primarily used to run Ingres based applications and has 16 IPC
ports.

The problem I am having is that once I reach approximately 40 processes
(As seen by "ps -eaf") an attempt to run another Ingres application
produces the message

    "spawn system process table is temporarily full"

I am fairly certain that I have run at least this many processes on other
386 systems without similiar problems.  Is there an upper limit to the
number of processes I can have running?  Is this limit adjustable
without modifying source code?  How would I adjust it if so?

Any insights, ideas, solutions would be greatly appreciated.  Please respond
by mail and/or post a message to this conference if you can shed some light
on this rather dismal situation.

Thanks,

-- 
Michael A. Israel               ||  uucp: mikei@ctdi.UUCP
                               	||        ...!uunet!cbmvax!ctdi1!ctdi
Communications Test Design Inc.	||
West Chester, PA                || Please direct all complaints to /dev/null

mikei@ctdi.UUCP (Mike Israel) (12/07/89)

Thanks to all those who have sent responses in what must be the fastest
turn-around ever.  Earlier I posted a question regarding process limits in
SYSV but I think I should have been more specific.

Essentially the problem relates to receipt of the message

       "spawn system process table is temporarily full"

I have, as suggested, checked my /etc/config/cf.d/stune file.  My
NPROC is set to 400  and MAXUP is set to 60.  (The upper limits are
400 and 60).  Nevertheless, after hitting 40 processes as seen by
ps -eaf, I am still unable to bring up another ingres application.
Note that all user existing processes are NOT owned by the same user
id, maybe 20 of them are owned by the same UID.

I have RTFM and have contacted both AT&T and Ingres about this problem.
Neither source has been much help.

Any ideas?

-- 
Michael A. Israel               ||  uucp: mikei@ctdi.UUCP
                               	||        ...!uunet!cbmvax!ctdi1!ctdi
Communications Test Design Inc.	||
West Chester, PA                || Please direct all complaints to /dev/null

mikei@ctdi.UUCP (Mike Israel) (12/15/89)

> 
> In article <791@ctdi.UUCP> I wrote:
> >I am having a problem which I am hoping a wizard can shed some light on.
> >
> >I am running AT&T Unix SYSV on an AT&T 386WGS with 16 meg of memory.  The
> >system is primarily used to run Ingres based applications and has 16 IPC
> >ports.
> >
> >The problem I am having is that once I reach approximately 40 processes
> >(As seen by "ps -eaf") an attempt to run another Ingres application
> >produces the message
> >
> >    "spawn system process table is temporarily full"
> >
> >I am fairly certain that I have run at least this many processes on other
> >386 systems without similiar problems.  Is there an upper limit to the
> >number of processes.


Thanks for the insights to all who provided them.  Oddly, it was not the
tunable system params which were causing the problem.  It turns out that 
one of our programmers had made a change to a file which resulted in an 
executable requiring about three meg of uninitialized data space.  Why this 
resulted in the above error is beyond me.  I would think we should have seen
some type of memory related error.  Anyway, the problem is now solved but 
thanks again for the information you did provide.  Maybe this info
will help you if you ever hit the same wall.


Michael A. Israel               ||  uucp: mikei@ctdi.UUCP
                               	||        ...!uunet!cbmvax!ctdi1!ctdi
Communications Test Design Inc.	||
West Chester, PA                || Please direct all complaints to /dev/null
-- 
Michael A. Israel               ||  uucp: mikei@ctdi.UUCP
                               	||        ...!uunet!cbmvax!ctdi1!ctdi
Communications Test Design Inc.	||
West Chester, PA                || Please direct all complaints to /dev/null