Stanley Hopcroft <[EMAIL PROTECTED]> writes: >Dear Folks, > >I am writing to ask for some clues dealing with an intolerable memory >leak of an application that embeds Perl. > >The application is Nagios 2.0b1 (http://www.Nagios.ORG), a GPL >availability monitor (like Big Brother or Mon). > >Nagios 1.2 would schedule service checks (eg of someones web frontend to >their database), popen() a pipe to the responsible process (quite often >a Perl program) and read the results. > >Nagios 2.0 retains this service check model (I think) but adds some >POSIX threads to handle the external command queue (for CGIs to ask for >checks to be rescheduled etc). > >1.2 + 5.005 Perl (FreeBSD 4.10 base system) leaks acceptably. > >2.0b1 + 5.8.5 threaded Perl (threaded (FreeBSD 4.10/pthread >library/FreeBSD port built with -DWITH_THREADS [from the port]) has an >unacceptable leak rate (the SIZE of the Nagios process embedding Perl >[shown by top] increases at about 1-2 MB/hour. At the moment I manage >this by monitoring the size of the process with a cron job and >restarting if its over a threshold. However, it would be nice to see >my abuse of Perl unequivocally succeed in this application rather than >Perl be abused instead [as well] as me). > >(IRRC Nag 1.2 + threaded Perl also had the bad leak rate) > >The FreeBSD 4.x Perl port does not build a threaded Perl by default, >however it appears to function Ok.
Hmm, I am not a FreeBSD user - I seem to recall that there were some issues with threads there - so it may be worth asking FreeBSD folk why they don't build a threaded perl. > >All suggestions as to where to start dealing with this problem are >welcome. I am not a professional developer so am unfamiliar with >identifying and resolving leaks. > >It seems to me (since few use embedded Perl but far more use Nagios >without it) >that the fault is in either the FreeBSD Perl or the >embedding support (the use of the Perl API hasn't changed between 1.2 >and 2.0, nor has the Perl shim that is called by Nagios). If Nagios without perl doesn't leak (and I assume given its use people would notice) that seems reasonable. However the perl API for a threaded perl is slightly different, so if use hasn't changed with a move to threaded perl that _may_ be the problem. If Nagios is itself "thread hot", then there may be some house keeping additions so that each new Nagios thread that calls perl allocates and cleans up correctly. > >Instrumenting the Perl shim (copied from perlembed) that determines >whether the Perl service check program is feasable as is any amount of >testbedding. Can I/we see the shim?