Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1383
  • Last Modified:

Configuring PID recycle pool on AIX

We have a number of client sites running a custom application against our database, each with 500+ users. The database has associated with it a number of dedicated daemon processes, one of which is responsible for "cleaning up" any processes that exit unexpectedly, occasionally leaving record locks and shared memory which could compromise database integrity. The client's application typically launches many short-lived processes. As a result it is possible for a process to exit and before the daemon has a chance to detect and clean it up, the OS has re-assigned the PID to another process. Needless to say this can cause all manner of problems to the daemon and at its worst, force the daemon to exit and require a database shutdown.

We cannot reduce the sleep time of the daemon any further. The client has gone to 7-digit PIDs anticipating that this will increase the size of the PID pool available to it and hence reduce the chance of the problem arising, but this does not appear to have an basis since the problem still recurs from time to time.

Is there some way to configure the kernel to either:
1) increase the pool size? (there is a pool of PIDs isn't there?)
2) specify some delay period before the PID is re-used?
3) some other way to prevent the situation arising?

Many thanks in advance!

Mark
0
UnifySupport
Asked:
UnifySupport
  • 2
  • 2
2 Solutions
 
woolmilkporcCommented:
Hi,
I guess your database is Universe?
If so, going to 7-digit PIDs is a mandatory approach. Are you sure that this configuration is actually in effect?
In AIX the PID assignment is somewhat unpredictable, to avoid creating a covert channel (allowing for conclusion on the OS by analyzing the sequence of PIDs used).
AIX PIDs are a combination of the PSLOT number (which can be reused immediately) and a Generation Count (max. 4096 afaik) which should prevent PIDs from being reused too rapidly. AIX PIDs are always even (except for 1, "init").
There is no "pool" of PIDs. You can't influence the creating or reusing of PIDs in AIX.
Did you talk to your database provider? I think there is nothing you can do on the AIX side.
 wmp
0
 
UnifySupportAuthor Commented:
It's actually a Unify database, I am a support engineer for Unify Corporation and the client has implemented 7-digit PIDs. However, I do not know whether they have max'd the generation count. I remember in a recent googling odyssey seeing PLSOT mentioned - there was also a second configuration variable involved but its name escapes me at the moment and I forgot to bookmark the site :(

Can you please tell me how I can determine what the generation count would be? I'm also guessing that 4096 (which does seem to ring a bell as the maximum value which can be ascribed) is not the default setting - yes?

Cheers,
Mark
0
 
woolmilkporcCommented:
4096 for Generation Count seems unchangeable. At least I have no idea at all where this could be done. If it were a tunable value it should appear with  "schedo -a" ("schedo -F -a" in AIX 6) or should be referenced by an environment variable. Both is not the case, as far as I can see.
This is the appropriate reference -
http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/summ_tun_params.htm 
You cam check whether it's actually 4096 -
- Take some unique, well-known process, like "cron"
- Issue "ps -ef | grep cron" and note the PID
- Issue "pstat -a | grep cron" and note the PSLOT (1st column)
- Perform an integer divide "PID / 4096" e.g. with ksh "echo $((PID/4096))"
- You will get PSLOT, q.e.d.
There is no other value besides the calculated PSLOT and the fixed Generation Count 0-4096 step 2, afaik.
 wmp
0
 
UnifySupportAuthor Commented:
Thank you, and please forgive the delay in completing this!
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now