17 Perl.exe processes

awilner has asked for the wisdom of the Perl Monks concerning the following question:

This is one of those "in between" kind of things between the cracks between Perl, IIS, CGI, Windows NT and possibly Apache, and I'm having a little trouble getting a grip on it.

I'm running Windows NT, M$ I.I.S. server, plugged in ActiveState Perl to do some CGI scripting (ported from Unix, do NOT ask why), everything seemed to be working fine but after a few weeks, suddenly the performance of the server was dead-slow. After looking at several things (including some nice people abusing our ftp site with cracked PS-2 games to the tune of 1.4GB, thank you, get a life please), we looked at the task manager -- 100% CPU utilization. Why? Seventeen Perl.exe processes partying hard. Couldn't kill them, but we could debug them, and kill them from the debugger. As soon as all 17 Perl.exe's were safely at breakpoints, the CPU load dropped precipitously.

Now, this system seems to have Oracle installed, and Oracle apparently decided to bring along Apache and Perl for the ride, 'cause we've got, like 1-1/2 Perls installed. Maybe that's relevant, maybe it's not. It sure looks like Oracle's 'bastardized' their Perl, there doesn't seem to be a full complement of modules out there, for instance.

Anyhow, I'm trolling for ideas. If I were on Unix, I could just "truss -f -p" on one of the perl binaries, but AFAIK there ain't no truss on NT, so I'm kind of lost.

Short of reinstalling a bunch of software (up to and including the O.S.), does anyone have any ideas for me to try?

Thank You O Great Masters.
- alden.

Comment on 17 Perl.exe processes

Replies are listed 'Best First'.
Re: 17 Perl.exe processes by $code or die (Deacon) on Sep 22, 2001 at 07:14 UTC
Under IIS, every time you access a .pl page, a new perl.exe process is created. They shouldn't hang around for long though - looks like you might have a script there which is not being friendly to your CPU! I would suggest looking at PerlIIS (which ships with ActivePerl) - this will load perl into the web server via ISAPI, so it doesn't need to load a new perl.exe for every script hit. By default, it adds the mapping .plx for PerlIIS scripts. You can copy those settings to .pl to make the switchover seamless. mod_perl under Apache doesn't have this problem. Simon Flack ($code or die) `$,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$, =~y'_"' ';eval"die";print $_,lc substr$@,0,3;`	[reply]
Re: 17 Perl.exe processes by blakem (Monsignor) on Sep 22, 2001 at 03:28 UTC
If you're looking for a windows `truss` (spelled `strace` in linux) You should take a look at 'Strace for NT'. -Blake	[reply] [d/l] [select]
Re: 17 Perl.exe processes by derby (Abbot) on Sep 22, 2001 at 14:42 UTC
alden, With great pennance, this monk admits to leaving perl cgi scripts in "debug" mode (-d flag set on interperter line). That tends to leave those perl scripts running (and leaking like nobody's business). So out of curiosity, are they running in debug mode. (Can you even do that with in win32 perl?) -derby	[reply]
Re: 17 Perl.exe processes by perrin (Chancellor) on Sep 22, 2001 at 08:22 UTC
Having 17 Perl processes running is not a bad thing, but having them take all of your CPU is. You need to look at the code for the CGI they were running and find out why it hogs so much processor time. You could also look at faster alternatives to CGI on NT, like PerlEx or VelociGen.	[reply]
Re: 17 Perl.exe processes by princepawn (Parson) on Sep 22, 2001 at 02:57 UTC
`17-PERL-EXE-ON-THE-WALL.... 17-PERL-EXE TAKE ONE DOWN, PASS IT AROUND 16-PERL-EXE-ON-THE-WALL....` [download]	[reply] [d/l]
Re: 17 Perl.exe processes by Stegalex (Chaplain) on Sep 22, 2001 at 20:47 UTC
Here's the right answer (I think). First off, in my most Clintonian voice I must bite my lip and say, "I feel your pain". Having said that, I am going to guess that you are using Oracle 8.1.5... which is a crap release, I know because I have it too and I have experienced the same problem. Now, do this: 1. Check all code to be sure that you are closing all cursors when you are done with them and that you are disconnecting your session when you are through. 2. Undef your statement handles when you are done. 3. Even if you have done all this, there are some garbage collection issues which sometimes prevent cursors from closing. The acid test is to select sql_text from v$open_cursor. My guess is that you will see open cursors. Kill the offending httpd process and you will see one less open cursor. You need to either rewrite the offending statements and/or write a script to detect when your httpd processes are hanging on to open cursors and kill the processes. For now, I am just restarting httpd every 2 hours but I should do something a little smarter.	[reply]
Re: 17 Perl.exe processes by alien_life_form (Pilgrim) on Sep 22, 2001 at 18:00 UTC
Greetings This is rather interesting, (as a figure of speech) because I am struggling with a similar problem with a perl/apache/COM setup. It goes like this: Script sits in a loop, polling a free-threaded COM server to return a resource and sleeping when it does not get one After 4/5 iterations, the call into COM (that's in Win32::OLE) locks up (i.e. never returns): Perl.exe just hangs around until killed. Same thing is not reproducible from within the debugger so some signal/event/threading model snafu appears to be responsible... what, exactly, beats me. And, how does one go about debugging such a problem? Cheers, alf	[reply]