How big is PID??

[caveman_piet]

Hi.

I inherited a system - and due to the design
and amount of work it does - the PID numbers
for the processes grow at an alarming rate.  :eek:  

Ok, I know it is an int - so that's a huge number
but for interest sake   :cool:  

Q - How big can a PID be in Linux? ie. the
 normal formatted output is only 5/6 digits
 eg. "top","ps without switches" etc.
Q - What happens if the numbers get used up?
    Will it wrap - and starting from where?
    or will it start displaying "#" overflow
    characters? maybe even halt init?

E--

Q - Is there a way of finding out how many
file handles are currently in use?
On a.n.other system - we reckon that is the
 problem ie. all the handles gets used up.
But proving it is something else!!

[ January 09, 2003: Message edited by: caveman ]

[voidmain]

I'm not 100% sure but I believe the highest PID number would be a two byte integer which would mean the highest would be 65535. So that would be the maximum number of simultaneous processes if it were true. I just logged in to one of my web servers with high uptime and my login process was 12724, yet my "ps" command was 15551. And the highest one is 32715 which to me would indicate that the highest process number might actually be a two byte signed integer (max would be 32768). And yes when the process numbers have all been used it does wrap and use unused process numbers although I don't believe at this point it is sequential. I could do some searching and give you the exact workings if you believe it will be useful to you.

As far as counting the number of open files you could do something like "# lsof | wc -l" although there may be something under /proc that would list it. You can control the open file limits. At the user level you would use the "ulimit" command in a login profile (see "man bash" under ulimit). At the kernel level I believe there is a setting you can add to /etc/sysctl.conf or echo a value to the special file under /proc to change the default open file limit (I don't know of the top of my head which one this is). Again, if you want exact locations I can get this for you too. I haven't ever had to up the limits in the past for any reason though.

[ January 09, 2003: Message edited by: void main ]

[caveman_piet]

TX void main - at least those are some pointers
for further reference.

Will have a look - and post something
if I find anything else of interest about this.

[choasforages]

i though i read something about somebody starting a half-million threads in under 3 seconds or soemthing it had to do with the new kernels and having the machine survive, and since each thread has its own pid

[voidmain]

Well that is possible on the 2.5.x kernels I believe, but not on the 2.4.x kernels. Here is the /usr/src/linux/include/linux/threads.h from 2.4.20:

Code: [Select]

You'll notice that PID_MAX is 0x8000 (32768 just as I suspected in my first note). But on 2.5.50 here is the "threads.h":

Code: [Select]

Which looks to have a limit of 4 million PIDs and I agree, that should be enough.    I personally have never ever come close to needing all 32768 PIDS on the 2.2/2.4 kernels. The largest number of threads I usually have running even on the biggest systems is only around a few hundred.

[caveman_piet]

Yep - I've been monitoring the system
the past day - and it wraps at 32k numbers.
Re-using unused numbers. Done that about
three times in the past 24 hrs.

Had to stop the jobs this evening to get some
bugs/enhancements in.

So the next test takes about 3-4 days of non
stop running. An thats where we reckon the
file handles gets used up - (nothing else
seems to make sense)..

In brief - 4 main processes each fork of 1 or 2
child processes which then activate the next
layer of jobs using "execl". These jobs can
run anything between 5 seconds and many minutes
depending on the system load and terminates
with an "_exit". After about 3-4 days -
everything apparently just stops. I haven't
seen this yet - so waiting,waiting waiting....

The system is home grown using suse 7.3 kernel - built on a 64 MB flash disc and 128 MB of memory.

Q -
{
if ((msgctl(y_QueueNo[Name], IPC_STAT, &Buffer)) < -1)
syslog(LOG_ERR, "QStat: Message ctl failed; %m");
return (Buffer.b_qnum);
}
usually gives back the number of entries on a queue. But blocks with no return
after a while when the queue is full. Any
suggestions?

TX.

[voidmain]

You wouldn't happen to have the source for the app in question would you? Have you checked for the number of "fopen()"s vs the number of "fclose()"s? And whether or not the program could terminate without closing a file?

Again you can use "lsof" to determine the number of files that are opened either totally or process by process. Do a "man lsof" for the extensive list of options.

[ January 10, 2003: Message edited by: void main ]