httpd - where are these zombies coming from?
I'm having trouble with zombies. Red Hat 7.1 on a Dell server with 1 GB memory. The following ps output shows a somewhat typical output. Sometimes there are no zombies, but most of the time there are several, and often as many as this. Performance often seems sluggish, and I am assuming that this is because of this problem, though I don't know that for sure. Turning off the database lowers usage and decreases the number of zombies, but I don't know if this is due to the database or to the lower usage. I can't figure out what is going on. Any help / suggestions would be much appreciated. $ ps -aux | grep apache root 30060 0.4 0.3 5564 3508 ?S13:36 0:04 /usr/local/apache apache 15892 0.0 0.3 5632 3612 ?S13:54 0:00 /usr/local/apache apache 16631 0.0 0.3 5632 3612 ?S13:55 0:00 /usr/local/apache apache 16690 2.2 1.1 16604 11372 ? S13:55 0:00 /usr/local/apache apache 16892 6.8 0.0 00 ?Z13:55 0:00 [httpd ] apache 16894 0.2 0.3 5632 3680 ?S13:55 0:00 /usr/local/apache apache 16903 0.3 0.0 00 ?Z13:55 0:00 [httpd ] apache 16911 0.2 0.3 5648 3696 ?S13:55 0:00 /usr/local/apache apache 16939 0.0 0.3 5640 3680 ?S13:55 0:00 /usr/local/apache apache 16957 25.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16962 0.0 0.3 5652 3692 ?S13:55 0:00 /usr/local/apache apache 16963 0.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16964 0.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16969 0.0 0.3 5636 3676 ?S13:55 0:00 /usr/local/apache apache 16970 0.0 0.3 5636 3684 ?S13:55 0:00 /usr/local/apache apache 16985 0.0 0.3 5636 3676 ?S13:55 0:00 /usr/local/apache apache 16987 0.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16989 0.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16991 1.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16992 0.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16993 0.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16994 0.0 0.0 00 ?Z13:55 0:00 [httpd ] apache 16995 0.0 0.3 5636 3676 ?S13:55 0:00 /usr/local/apache apache 16996 1.0 0.3 5636 3676 ?S13:55 0:00 /usr/local/apache admin16998 0.0 0.0 1740 604 pts/0S13:55 0:00 grep apache My httpd.conf has the following: KeepAlive Off MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 10 MaxSpareServers 15 StartServers 15 MaxClients 35 MaxRequestsPerChild 300 /usr/local/apachessl/bin/httpd -V Server version: Apache/1.3.26 (Unix) Server built: Aug 10 2002 01:35:37 Server's Module Magic Number: 19990320:13 Server compiled with -D EAPI -D HAVE_MMAP -D HAVE_SHMGET -D USE_SHMGET_SCOREBOARD -D USE_MMAP_FILES -D HAVE_FCNTL_SERIALIZED_ACCEPT -D HAVE_SYSVSEM_SERIALIZED_ACCEPT -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D HTTPD_ROOT="/usr/local/apachessl" -D SUEXEC_BIN="/usr/local/apachessl/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/httpd.scoreboard" -D DEFAULT_LOCKFILE="logs/httpd.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" -D ACCESS_CONFIG_FILE="conf/access.conf" -D RESOURCE_CONFIG_FILE="conf/srm.conf" I built it with: -rw-r--r--1 adminadmin 2303147 Aug 9 22:10 apache_1.3.26.tar.gz -rw-r--r--1 adminadmin 372525 Aug 9 22:14 mod_perl-1.27.tar.gz -rw-r--r--1 adminadmin 753241 Aug 9 23:27 mod_ssl-2.8.10-1.3.26.tar.gz -rw-r--r--1 adminadmin 2170570 Aug 10 01:22 openssl-0.9.6g.tar.gz Thanks, Tim
Re: mod_perl vs. C for high performance Apache modules
>So I'm trying to show that mod_perl doesn't suck, and that it is, in >fact, a reasonable choice. I think one of the selling points for mod_perl is its extensibility: modules can be written in C. Depending on the C code you have access to, a good solution might be to try to wrap it into mod_perl modules. Tim
Re: Help with converting from plain CGI to mod_perl
>Depending on how you log into the system, the >user will connect to different databases. When they do this, I store the >Database Handle from DBI/DBD as $main::dbh. This variable has the scope of >"the length of processing the request" and then should become undef. Easy >under normal CGI, because you start with a whole new memory space. If I make >this a variable in db_ora.pm, it then is persistant "forever"--or until I >restart apache. If I make it a local in foo.pl, it has the right lifespan, >but I can't figure out how to address is down in db_ora.pm--particularly >with it's not just "foo.pl" but 50 different top-level scripts. > >Can someone help? Pointer to documentation? Am I staring at something so >obvious that it would bite me? Walt, I was not able to keep persistent connections without leaking memory until I switched to Apache::DBI. It did mean that I had to limit the number of processes to within the RAM available and make sure keep-alives were off, but this was fine. Tim
Re: Reload Modules on NT Apache
>I am using mod-perl, and I am in the development stages of coding. Each time >I make a code change to a module, I must restart apache. I know there must >be docs for this, but I cannot find them from the apache web site. Could >someone assist me in finding those? Or if someone knows of a simple way to >accomplish this task, please advise. Scott, There is a module called StatINC which is supposed to solve this problem. I've had trouble with it but it is probably something I am doing wrong as I never fully investigated. Alternatively, depending what you are doing, you might be able to add the packages to the script which would otherwise "use" them during development so that they get recompiled every time. This wouldn't work very well if you are sharing the modules between a bunch of programs, obviously, but if you are trying to debug something it might help. Tim
ssl encryption
When apache is serving a ssl connection, I assume that everything sent back and forth between the server and the client is encrypted. I want an mod_perl script to encrypt/decrypt credit card numbers obtained over the ssl connection for storage in a db on the server. Is there any access to the same routines that apache is using for the encryption or do I have to use some other module. If I have to use another module, what would be a good choice? Thanks, Tim
Re: Apache::DBI missing methods?!
I don't know if there is a downside (perhaps I can't use status?), but when I commented out the 'Apache::Status->menu_item( ...' section, it seemed to work ok. Tim >On Tue, 15 May 2001, James Croft wrote: > >> >> Hi, >> >> I've just joined the list looking for an answer to this. A couple of >> others have posted the same problem but I couldn't find any answers. >> >> I'm running RH6.2 with standard Apache, perl and mod_perl rpms. I'm >> hitting a brick wall if I include a 'PerlModule Apache::DBI' line in >> httpd.conf - Apache starts up but shuts down immediately. I created a test >> script that just use's the module and I get the following error >> >> Can't locate object method "module" via package "Apache" at >> /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 202. BEGIN >> failed--compilation aborted at ./test.pl line 4. >> >> Which must be what's frying httpd. >> >> Does anyone know what's going on? Any help or suggestions appreciated. > >Have you tried: >http://perl.apache.org/guide/troubleshooting.html#Can_t_locate_object_method_get_ >or >PREREQUISITES >Note that this module needs mod_perl-1.08 or higher, >apache_1.3.0 or higher and that mod_perl needs to be >configured with the appropriate call-back hooks: > > PERL_CHILD_INIT=1 PERL_STACKED_HANDLERS=1. > > > > >_ >Stas Bekman JAm_pH -- Just Another mod_perl Hacker >http://stason.org/ mod_perl Guide http://perl.apache.org/guide >mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ >http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
understanding memory via ps -ely | grep http
I have been trying to reduce/tune the memory requirements of an online game which uses mod_perl (Apache::Registry). I have read the suggestions at http://perl.apache.org/tuning/ and am trying to follow them. The first suggestion is to preload the modules by including Perlrequire /var/www/perllib/startup.perl in httpd.conf and then in startup.perl doing: #! /usr/local/bin/perl use strict; use lib "/var/www/perllib"; use Apache::DBI (); use mymodules (); 1; According to the web page: >What this does is pull in all of the code used by the programs (but >does not import any of the module methods) into the main HTTPD >process, which then creates the child processes with the code >already in place. I have been monitoring memory usage with the command: ps -ely | grep http and getting output that looks something like this. S UID PID PPID C PRI NI RSS SZWCHAN TTY TIME CMD S 1003 318 1 0 40 18 4432 40960? ?4:37 cshttpd S 1003 345 318 0 40 18 3320 40920? ?0:02 cshttpd S 0 2835 1 0 41 20 8776 10344? ?0:34 httpd S 60001 4895 2835 0 41 20 13272 18872? ?0:06 httpd S 60001 4894 2835 0 41 20 13280 18872? ?0:07 httpd I understand that the RSS is the resident size in KB and the SZ column is the size of the process, but what should I be seeing in the way of reduced memory? The 13MB/18MB is not much different from when I don't preload anything. Should I be seeing something else? I probably am not understanding what to look for. Any suggestions or observations would be appreciated. Thanks, Tim
Apache::DBI strategy/philosophy
I have been using DBI without Apache::DBI and have been simply storing db connections in a global variable as a sort of poor man's persistent connection when running under Apache::Registry. Now I want to do things "right" and am trying to understand Apache::DBI. Before looking at the module I imagined that it would work by providing a library of persistent connections. You would check a connnection out of the library, use it, and then put it back when you are done, like checking a book out of the library. If you disconnected the connection, you just wouldn't return it, and the pool would have to create a new connection for the next user. But this is not the way Apache::DBI works. Instead, if I understand correctly after glancing at the module this morning, two consecutive identical connect calls will return the same connection! Why isn't this a problem? Is the assumption that two different transactions will use different user/pwd combinations? Thanks, Tim
Re: "headless" operation
I am guessing that the "headless" version is what I do this when I am doing a shockwave piece which calls cgi scripts. I create an html version which provides a browser interface, albeit more boring, to the same basic code so that I can more easily test the cgi side. My strategy is to create two different versions of an "outputer" class, and within the code always call it to do the printing. For example $outputer->printResults( $x, $y); Then I create one outputer class which outputs proper html and one which outputs what the shockwave piece needs (much smaller). Then depending on parameters in the cgi calls or in the database, I instantiate the proper outputter to handle the call. Tim >[EMAIL PROTECTED], > >for a future project I'm in the need to support two different ways how our >web based service can be accessed: >1.) The traditional way: Handling user requests through a browser >2.) The "headless" way: Handling under-the-hood requests which basically >perform the same service as in 1, but without ever generating valid HTML. > >Of course I want to write application logic only once and reuse it for both >scenarios above. > >I looked at the various template/component systems (HTML::Mason, Embperl, >HTML::Template) and get the impression that all of them are very much fall >into category one, where they in some way or another expect to be driven >from a browser. >I checked into xmlrpc (http://www.xmlrpc.com) as a way to perform the >under-the-hood operation, but it seems to become aweful when trying to >integrate it with a mod_perl driven site using one of the >template/component systems. > >What I'm basically planning to create is an application framework which >does not tie into the HTML generation process, but is invoked from a driver >that sends either browser-input or headless input to the application logic >and then filters the output to generate either headless responses (XML >probably) or HTML output. > >Has anybody done somthing like this before? Are there any pointers you >mod_perl'ers want to share with me? > >Thanks in advance > Tobias Hoellrich, Adobe Systems
