All, I'm not sure how to word this question but we're noticing a lot of our asterisk boxes no longer have multiple asterisk child processes. i.e. doing a 'ps ax' reveals only 1 asterisk PID when normally I'm used to seeing 8+ .. There is no rhyme or reason to it, and we're using the safe_asterisk script which has always worked in the past. Ast 1.2.4, zap 1.2.4, naturally.. All my research has revealed nothing, regarding this, any suggestions? What I'm worried about, of course, is the single process getting overloaded with CPU calls and potentially denying service. Matt @ NetLogic
Matt Schulte wrote:> All, I'm not sure how to word this question but we're noticing a lot of > our asterisk boxes no longer have multiple asterisk child processes. > i.e. doing a 'ps ax' reveals only 1 asterisk PID when normally I'm used > to seeing 8+ .. There is no rhyme or reason to it, and we're using the > safe_asterisk script which has always worked in the past. Ast 1.2.4, zap > 1.2.4, naturally..This is completely normal; if your distro is using LinuxThreads, then you will see multiple processes, but if it is using NPTL (as current distros do), then you will only see one process because the threads are not shown as processes.
On Thursday 02 March 2006 22:19, Matt Schulte wrote:> All, I'm not sure how to word this question but we're noticing a lot of > our asterisk boxes no longer have multiple asterisk child processes. > i.e. doing a 'ps ax' reveals only 1 asterisk PID when normally I'm used > to seeing 8+ .. There is no rhyme or reason to it, and we're using the > safe_asterisk script which has always worked in the past. Ast 1.2.4, zap > 1.2.4, naturally.. > > All my research has revealed nothing, regarding this, any suggestions? > What I'm worried about, of course, is the single process getting > overloaded with CPU calls and potentially denying service. > > Matt @ NetLogicMatt On 2.4 kernels you would be using the LinuxThreads implementation of POSIX threads. This emulated the POSIX threading model with some limitations - signals could only be delivered to the master thread - there was a 'hidden' control thread etc... Context switching performance in LinuxThreads was known to be poor (sometimes measured in whole seconds) IBM and RedHat worked on solving this problem - IBM's effort (NGPT) was abandoned in favour of REdHat's (NPTL). NPTL was introduced in RedHat 9 (as I remember). Most modern distro's now use NPTL and one can tell this by doing 'ps ax' and seeing only one asterisk task instead of many. Asterisk without NPTL is probably not good for high thruput sites. And Gentoo users beware - only 2006.0 has adopted NPTL as default. Previously one had to rebuild the toolchain by specifying USE flags "nptl nptlonly" to get NPTL threads (and this takes a long time...) Have u upgraded to a more modern distro recently ? Paul
On Thu, Mar 02, 2006 at 02:19:29PM -0600, Matt Schulte wrote:> All, I'm not sure how to word this question but we're noticing a lot of > our asterisk boxes no longer have multiple asterisk child processes. > i.e. doing a 'ps ax' reveals only 1 asterisk PID when normally I'm used > to seeing 8+ .. There is no rhyme or reason to it, and we're using the > safe_asterisk script which has always worked in the past. Ast 1.2.4, zap > 1.2.4, naturally.. > > All my research has revealed nothing, regarding this, any suggestions? > What I'm worried about, of course, is the single process getting > overloaded with CPU calls and potentially denying service.A single process, just as before. Multiple theads of it, as before. Take a look at /proc/<PID>/tasks Also, try 'ps auxm' rather than 'ps aux' . See ps(1) and look for "threads". -- Tzafrir Cohen | tzafrir@jbr.cohens.org.il | VIM is http://tzafrir.org.il | | a Mutt's tzafrir@cohens.org.il | | best ICQ# 16849755 | | friend