Re: mod_perl_traps && my($var) = '';
my ($var) = ('');
Vasily Petrushin
+7 (095) 2508363
http://www.interfax.ru
mailto:[EMAIL PROTECTED]
Re: Performance Tuning -- How do I determine the correct value forRLimitMEM?
On Wed, 14 Feb 2001, Franco Finstad wrote: > I have a modper/DBI/Oracle8i/solaris2.7 site and I'm having performance > problem because I have too many apache processes that are too big. The > machine grinds to a crawl for a normal amount of users. > > The problem is that at server startup I immediately have a bunch of apache > process that are already using swap, It's ok on Solaris. > but I have 4GB of RAM. What's going > on?? Try MaxRequestsPerChild from 50 to 100 in httpd.conf This because mod_perl is not freeing memory after serve any request. > > See the output of top below. > > It looks like the apache processes are not using all the available memory. > From top, RES gets lower than SIZE, why? > Should I adjust RLimitMEM, and if so, how to I determine the correct value? > > Any help is greatly appreciated. > > ** Output of top * > load averages: 0.06, 0.07, 0.07 > 18:11:14 > 120 processes: 119 sleeping, 1 on cpu > CPU states: 94.7% idle, 0.0% user, 5.0% kernel, 0.3% iowait, 0.0% swap > Memory: 4096M real, 2834M free, 1235M swap in use, 6252M swap free > > PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND > 501 oracle 1 00 2480K 2048K sleep 6:14 2.02% top > 1511 ffinstad 1 00 2440K 2064K cpu20:01 1.92% top > 906 nobody 9 580 46M 22M sleep 0:12 0.07% beans_adapter_e > 1501 ffinstad 1 480 1824K 1344K sleep 0:00 0.06% ksh > 393 oracle 1 580 374M 347M sleep 0:01 0.02% oracle > 163 root 5 580 2848K 2280K sleep 0:00 0.02% automountd > 114 root 6 500 2288K 1440K sleep 0:00 0.01% keyserv > 196 root 8 500 2768K 2328K sleep 0:00 0.01% nscd > 1499 root 1 380 1760K 1368K sleep 0:00 0.00% in.telnetd > 1163 nobody 4 480 33M 21M sleep 0:04 0.00% httpsd > 1162 nobody 4 580 33M 20M sleep 0:04 0.00% httpsd > 1232 oracle 1 20 374M 351M sleep 0:03 0.00% oracle > 1153 nobody 4 500 33M 21M sleep 0:03 0.00% httpsd > 1235 oracle 1 520 374M 352M sleep 0:03 0.00% oracle > 1164 nobody 4 580 33M 21M sleep 0:03 0.00% httpsd > > > ** perl5 configuration *** > Embedded Perl version 5.00503 for Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 > (Unix) mod_perl/1.21 > > Apache::DBI 0.87 > DBI 1.13 > DBD::Oracle 1.06 > > Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: > Platform: > osname=solaris, osvers=2.7, archname=sun4-solaris > uname='sunos cabinet 5.7 generic_106541-05 sun4u sparc sunw,ultra-5_10 ' > hint=recommended, useposix=true, d_sigaction=define > usethreads=undef useperlio=undef d_sfio=undef > Compiler: > cc='gcc', optimize='-O', gccversion=2.8.1 > cppflags='-I/usr/local/include' > ccflags ='-I/usr/local/include' > stdchar='char', d_stdstdio=define, usevfork=false > intsize=4, longsize=4, ptrsize=4, doublesize=8 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 > alignbytes=8, usemymalloc=y, prototype=define > Linker and Libraries: > ld='gcc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib > libs=-lsocket -lnsl -ldl -lm -lc -lcrypt > libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' > cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' > > > > > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Re: Segfault: apache-1.3.17+modperl-1.25
On Wed, 14 Feb 2001, Gary Algier wrote: > My children are segfaulting. > > I have: > Solaris 2.6 (w/all latest patches installed right after the OS) > Perl 5.6.0 (no largefiles, no threads) > Apache 1.3.17 > modperl 1.25 (as a DSO) > gcc 2.95.2 (using Sun's as and ld I had same problems. Try to compile mod_perl statically. Works fine. > > If I run apache leaving out: > LoadModule perl_modulelibexec/libperl.so > AddModule mod_perl.c > it runs just fine. Put them in and the child seg faults. I did manage > to gdb the process and it says: > > Program received signal SIGSEGV, Segmentation fault. > 0xef0a2e00 in perl_header_parser () > (gdb) where > #0 0xef0a2e00 in perl_header_parser () > #1 0x20714 in run_method () > #2 0x208e4 in ap_header_parse () > #3 0x3d9bc in process_request_internal () > #4 0x3ded0 in ap_process_request () > #5 0x314c8 in child_main () > #6 0x31854 in make_child () > #7 0x31dcc in perform_idle_server_maintenance () > #8 0x32630 in standalone_main () > #9 0x32f64 in main () > > Unfortunately, there are no debugging symbols so it is limited. It wasn't > easy getting this, though if it would help I will endeavor to rebuild > everything with debugging symbols and try again. > > In general, I know that DSOs are working as I runtime load the max. I also > load php 4.0.4pl1 that way and it works. > > Any ideas? Does the trace help? > > > > -- > Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 > Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 > >A self-addressed envelope would be addressed "envelope." > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Re: Squid and mod_perl. Is it a good company?
They are very good and friendly company. I'm using this bundle over two years under high load. All things works fine. I can send you all configuration tips and comments, if you have any problems. Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Re: mod_vhost_alias / ProxyPassReverse problem
On Mon, 12 Feb 2001, Ime Smits wrote:
> Hi,
>
> I have a mod_perl backend listening on *:81 and a proxy in front of it
> listening on *:80, both using mod_vhost_alias configured with
>
I'm using squid in httpd-accellerator mode on port 80.
And I have no problems with redirects and with any other specific things
in web sites programming process.
And in fact, squid eating less memory and cpu resources than apache proxy
module.
> VirtualDocumentRoot /www/site/%0
>
> i.e. www.mydomain.com will have /www/site/www.mydomain.com as it's document
> root. The frontend has
>
>
> RewriteEngine On
> ...
> RewriteRule \.(jpg|png|swf|css|html|txt|cgi)$ - [last]
> RewriteRule ^/(.*)$ http://%{HTTP_HOST}:81/$1 [proxy]
>
>
> Now this all works fine except when a client side redirect using meta
> http-equiv tags occurs, in which case the hostname part in the url holds a
> :81 suffix, effectively bypassing the proxy. Now, the problem is I cannot
> use ProxyPassReverse because it doesn't eat hostnames as its first argument.
>
> What's the advisable thing here? Should I consider hacking around in
> src/main/util_uri.c? Can this be fixed by a fixup handler (maybe replacing
> r->uri_components->port?) Or should I just drop mod_vhost_alias on the
> backend and start using perl sections to do a directory scan on /www/site
> and setup all my VirtualHosts that way? Has anybody done this before?
>
> Ime
>
>
Vasily Petrushin
+7 (095) 2508363
http://www.interfax.ru
mailto:[EMAIL PROTECTED]
Re: mod_perl/apache mysql memory usage
Xvnc > 1 root 0 0 460 460 388 S 0 0.0 0.5 0:04 init > 2 root 0 0 00 0 SW 0 0.0 0.0 0:00 kflushd > 3 root 0 0 00 0 SW 0 0.0 0.0 0:00 kupdate > 4 root 0 0 00 0 SW 0 0.0 0.0 0:00 kpiod > 5 root 0 0 00 0 SW 0 0.0 0.0 0:00 kswapd > 6 root -20 -20 00 0 SW< 0 0.0 0.0 0:00 mdrecoveryd > 291 bin0 0 308 288 228 S 0 0.0 0.3 0:00 portmap > 307 root 0 0 392 380 328 S 0 0.0 0.4 0:00 apmd > 360 root 0 0 516 508 420 S 0 0.0 0.5 0:00 syslogd > 371 root 0 0 668 656 316 S 0 0.0 0.7 0:00 klogd > 387 daemon 0 0 312 296 232 S 0 0.0 0.3 0:00 atd > 403 root 0 0 548 540 452 S 0 0.0 0.6 0:00 crond > 423 root 0 0 444 436 368 S 0 0.0 0.4 0:00 inetd > 439 root 0 0 448 436 368 S 0 0.0 0.4 0:00 lpd > 462 root 0 0 868 868 672 S 0 0.0 0.9 0:00 in.telnetd > 463 root 0 0 1116 1116 868 S 0 0.0 1.2 0:00 login > 464 jaimeren 0 0 956 956 768 S 0 0.0 1.0 0:00 bash > 478 root 0 0 1064 1064 704 S 0 0.0 1.2 0:00 su > 479 root 5 0 988 988 756 S 0 0.0 1.1 0:00 bash > 505 root 0 0 808 664 516 S 0 0.0 0.7 0:00 sendmail > 522 root 0 0 340 312 268 S 0 0.0 0.3 0:00 gpm > 539 xfs0 0 1088 1080 584 S 0 0.0 1.2 0:00 xfs > 590 root 0 0 392 332 252 S 0 0.0 0.3 0:00 S99local > 592 root 0 0 840 840 688 S 0 0.0 0.9 0:00 safe_mysqld > 621 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 623 root 0 0 600 516 424 S 0 0.0 0.5 0:00 smbd > 634 root 0 0 756 708 572 S 0 0.0 0.8 0:00 nmbd > 639 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 640 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 641 root 0 0 1288 772 564 S 0 0.0 0.8 0:00 named > 643 root 0 0 384 384 316 S 0 0.0 0.4 0:00 mingetty > 644 root 0 0 384 384 316 S 0 0.0 0.4 0:00 mingetty > 645 root 0 0 384 384 316 S 0 0.0 0.4 0:00 mingetty > 646 root 0 0 384 384 316 S 0 0.0 0.4 0:00 mingetty > 647 root 0 0 384 384 316 S 0 0.0 0.4 0:00 mingetty > 648 root 0 0 384 384 316 S 0 0.0 0.4 0:00 mingetty > 649 root 0 0 1004 1004 944 S 0 0.0 1.1 0:00 gdm > 657 root 0 0 11016 10M 1812 S 0 0.0 12.6 0:00 X > 658 root 0 0 776 736 668 S 0 0.0 0.8 0:00 gdm > 665 gdm0 0 3156 3156 2400 S 0 0.0 3.6 0:00 gdmlogin > 683 root 0 0 4116 4116 3004 S 0 0.0 4.7 0:02 kwm > 684 root 0 0 3736 3736 2712 S 0 0.0 4.2 0:00 kbgndwm > 685 root 0 0 400 344 264 S 0 0.0 0.3 0:00 startkde > 690 root 0 0 656 656 512 S 0 0.0 0.7 0:01 autorun > 711 root 0 0 2116 1068 940 S 0 0.0 1.2 0:01 kfm > 712 root 0 0 3692 3692 2688 S 0 0.0 4.2 0:00 krootwm > 713 root 0 0 2812 1952 1612 S 0 0.0 2.2 0:01 kpanel > 728 root 0 0 436 436 336 S 0 0.0 0.4 0:00 esd > 764 root 0 0 7472 7472 7312 S 0 0.0 8.5 0:00 httpd > 765 nobody 0 0 8608 8608 5480 S 0 0.0 9.8 0:00 httpd > 766 nobody 0 0 8648 8648 5496 S 0 0.0 9.8 0:00 httpd > 767 nobody 0 0 8448 8448 5512 S 0 0.0 9.6 0:00 httpd > 768 nobody 0 0 8636 8636 5480 S 0 0.0 9.8 0:00 httpd > 769 nobody 0 0 8684 8684 5492 S 0 0.0 9.9 0:01 httpd > 797 root 0 0 2396 2376 2004 S 0 0.0 2.7 0:00 smbd > 798 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 799 nobody 0 0 8412 8412 5524 S 0 0.0 9.6 0:00 httpd > 800 nobody 0 0 8392 8392 5512 S 0 0.0 9.6 0:00 httpd > 801 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 804 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 805 nobody 0 0 8388 8388 5512 S 0 0.0 9.6 0:00 httpd > 806 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 807 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 808 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 809 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 810 root 0 0 2348 2348 1384 S 0 0.0 2.6 0:00 mysqld > 822 nobody 0 0 7480 7480 7320 S 0 0.0 8.5 0:00 httpd > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Re: Error reporting mod_perl 1.25 + apache 1.3.17
I removed this problem on Solaris 8 SPARC by compiling perl 5.6.0 with -Ubincompat and -Uuselargefiles and compiling mod_perl 1.25 + apache 1.3.17 statically. Now httpd process eating less memory :). It's cool. On Tue, 6 Feb 2001, dima wrote: > > I used to have all these seg faults when dealing with apache1.3.14 and > mod_perl1.24_01 (perl5.6.0/redhat 6.2) when built as DSO. As soon as you > get a request through log files just get flooded with segmentation faults. > However when I switched over to apache1.3.17 + mod_perl1.25 everything > goes on just fine. > Try using PERL_USELARGEFILES=0 when building mod_perl too. > > cheers, > dima > > On Mon, 5 Feb 2001, modperl wrote: > > > Actually My current builds are very similar. 1.3.17+1.25w/5.6.0 on > > slackware linux 7.1, dually intel boxes. > > Works fine and while watching error logs i haven't seen any > > segfaults. returns our pages just fine. > > > > Scott > > > > On Mon, 5 Feb 2001, Paul Lindner wrote: > > > On Mon, Feb 05, 2001 at 06:41:00PM +, G.W. Haywood wrote: > > > > Hi there, > > > > On Mon, 5 Feb 2001, Matisse Enzer wrote: > > > > > I compiled perl 5.6 and Apache 1.3.17 using gcc egcs-2.91.66 > > > > > on a RH Linux 6.1 system. > > > > I'm sure there must be people on this List who have successfully built > > > > mod_perl systems using exactly the packages you have mentioned. > > > > Anyone care to confirm that? > > > I've seen some strange segementation fault problems with mod_perl > > > 1.25. I have not had the time to document these. > > > Environment is similar to others: mod_perl 1.25, apache 1.3.17, perl > > > 5.00503, solaris 2.6... > > > > > > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Error reporting mod_perl 1.25 + apache 1.3.17
bash-2.03# perl -V Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris-thread-multi uname='sunos sun 5.8 generic_108528-04 sun4u sparc sunw,ultra-4 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O2', gccversion=2.95.2 19991024 (release) cppflags='-D_REENTRANT -fno-strict-aliasing -I/usr/local/include' ccflags ='-D_REENTRANT -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lposix4 -lpthread -lc -lcrypt -lsec libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under solaris Compiled at Jan 30 2001 16:09:51 @INC: /usr/local/lib/perl5/5.6.0/sun4-solaris-thread-multi /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris-thread-multi /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . Version of mod_perl 1.25, 1.24 Version of apache 1.3.17, 1.3.12 Options given to mod_perl's Makefile.PL USE_DSO=1 EVERYTHING=1 Server configuration details Tryed 2 httpd building options with LIBS=-lpthread and without No more special details used t/conf/httpd.conf Relevant sections of your ErrorLog (make test's is: t/logs/error_log) [Fri Feb 2 17:35:26 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.25 Perl/v5.6.0 configured -- resuming normal operations [Fri Feb 2 17:35:26 2001] [warn] [notice] child_init for process 18609, report any problems to [no address given] [Fri Feb 2 17:35:26 2001] [warn] [notice] child_init for process 18608, report any problems to [no address given] 'make test' fails, the output of 'make test TEST_VERBOSE=1' bash-2.03# make test TEST_VERBOSE=1 cp t/conf/mod_perl_srm.conf t/conf/srm.conf ./apaci/load_modules.pl ../apache_1.3.17/src ../apache_1.3.17/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...done /usr/local/bin/perl t/TEST 1 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. *** Error code 146 make: Fatal error: Command failed for target `run_tests' OS: bash-2.03# uname -a SunOS sun 5.8 Generic_108528-04 sun4u sparc SUNW,Ultra-4 Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
mod_perl 1.25 + perl 5.6
Hi, people. I have a problem with perl 5.6 + mod_perl 1.25 + apache 1.3.17 After successful biulding and configuring an apache, httpd started successfully, but after recieve any request the child process are dieing by signal 11 (Segmentation Fault). Operating System is Sun Solaris 8 for SPARC, 64bit. error_log - [Tue Jan 30 17:57:26 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.25 configured -- resuming normal operations [Tue Jan 30 17:58:51 2001] [notice] child pid 17005 exit signal Segmentation Fault (11) - May be I must say any special configuration parameters when building perl 5.6 and apache? Can You advice? Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Re: Repost with typos corrected--Instance variable inheritance
On Tue, 30 Jan 2001, Ken Williams wrote:
> [EMAIL PROTECTED] (Joe Schaefer) wrote:
>
> >
> >"Christopher L. Everett" <[EMAIL PROTECTED]> writes:
> >
> >> sub handler ($$) {
> >> my ($self, $q);
> >>
> >> my $r = Apache::Request->new($q);
> >>
> >> # send headers here
> >>
> >> print $self->name;
> >
> >$self is a string ("simian"), not an object ref; for this
> >line to work, you need to make one by calling "new" somewhere,
> >or guard against misuse via:
> >
> >print $self->name if ref $self;
>
>
> Technically there's nothing wrong with that, it'll call the name()
> method of the "simian" class. It may not be what you want to do, but
> it's legal.
>
> The error is that the name() method doesn't expect to be called as a
> class method, it's an object method. So as Joe points out, you could
> add the following line:
>
>sub handler ($$) {
> my ($self, $q);
>
> -> $self = $self->new(); ??? 8-[ ] who is $self->new() ???
$self = PackageName->new();
> my $r = Apache::Request->new($q);
>
> # send headers here
>
> print $self->name;
> return OK;
>}
>
>
> ------
> Ken Williams Last Bastion of Euclidity
> [EMAIL PROTECTED]The Math Forum
>
Vasily Petrushin
+7 (095) 2508363
http://www.interfax.ru
mailto:[EMAIL PROTECTED]
Re: Anyone using "virtual server" for mod_perl hosts?
Bekman, I'm sorry. Excuse me, Stas... On Tue, 30 Jan 2001, Martin Langhoff wrote: > hi, > > due to some fairly complex issues (money, or lack thereof), I am > considering turning a mod_perl server from co-location into a 'virtual > server' service, like Verio offers. > > Far from asking if it is a good solution (I know it is not) I'd like to > know if its feasible. I have been managing remote co-located servers for > quite a while, so I am already used to the impotence of not being able > to kick the box when it misbehaves. In fact, last time I got really > angry at a box I got a my fist cut, hitting it. So remote boxen might > turn out to be healthier for my temper ;) > > Is anyone using a 'virtual server' succesfully? Or have a horror story? > Know of companies other than verio? > > Oh! and before anyone points it out, yes, it low -- low -- low traffic. > The current server never gets more than 0.5 load average. > > > > > Martin > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Re: Anyone using "virtual server" for mod_perl hosts?
On Tue, 30 Jan 2001, Martin Langhoff wrote: > hi, > > due to some fairly complex issues (money, or lack thereof), I am > considering turning a mod_perl server from co-location into a 'virtual > server' service, like Verio offers. Check Berkman's stories about mod_perl hosting at http://apachetoday.com. There was some links to mod_perl hosting providers. > > Far from asking if it is a good solution (I know it is not) I'd like to > know if its feasible. I have been managing remote co-located servers for > quite a while, so I am already used to the impotence of not being able > to kick the box when it misbehaves. In fact, last time I got really > angry at a box I got a my fist cut, hitting it. So remote boxen might > turn out to be healthier for my temper ;) > > Is anyone using a 'virtual server' succesfully? Or have a horror story? > Know of companies other than verio? > > Oh! and before anyone points it out, yes, it low -- low -- low traffic. > The current server never gets more than 0.5 load average. > > > > > Martin > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
RE: Advice needed. (web app. performance)
On Tue, 30 Jan 2001, Vladislav Safronov wrote: Try Unix sockets > What about this idea: > > open N 'ispell -a' processes for writing and reading at httpd start up, > save their descriptors into an array in some Perl module and then > mark decriptors in the table then as "busy" or "idle". But the question > is how to share this dynamicly modified table among all httpd processes? .. > > / vlad > > > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Re: Runaways
On Mon, 29 Jan 2001, Robert Landrum wrote: > I have some very large httpd processes (35 MB) running our mod_perl are not freeing memory when httpd doing cleanup phase. Me too :). Use the MaxRequestPerChild directive in httpd.conf. After my investigations it seems to be only way to build a normal system. There are no 100% right worked ways, supplied with apache. mod_status can provide you some info, but... On Solaris 2.5.1, 7, 8 you can use /usr/proc/bin/pmap to build a map of the httpd process. > application software. Every so often, one of the processes will grow > infinitly large, consuming all available system resources. After 300 > seconds the process dies (as specified in the config file), and the > system usually returns to normal. Is there any way to determine what > is eating up all the memory? I need to pinpoint this to a particular > module. I've tried coredumping during the incident, but gdb has yet > to tell me anything useful. > > I was actually playing around with the idea of hacking the perl > source so that it will change $0 to whatever the current package > name, but I don't know that this will translate back to mod perl > correctly, as $0 is the name of the configuration from within mod > perl. > > Has anyone had to deal with this sort of problem in the past? > > Robert Landrum > Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
