Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

memory leak with perl5.8/freebsd/mod_perl 1.29

 

 

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


snacktime at gmail

Jul 20, 2005, 9:04 AM

Post #1 of 8 (707 views)
Permalink
memory leak with perl5.8/freebsd/mod_perl 1.29

Before I spend a whole lot of time on this I'm curious if someone else
has run across this. This is mod perl 1.29.

We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
5.8.7. This included reinstalling around 50 perl modules (some to new
versions) from the freebsd ports. Ever since the upgrade, apache
increases in memory by about a third of it's original size whenever by
it restarts via SIGHUP.

Does this ring a bell for anyone, or do I start debugging from scratch?

Chris


stas at stason

Jul 20, 2005, 9:46 AM

Post #2 of 8 (692 views)
Permalink
Re: memory leak with perl5.8/freebsd/mod_perl 1.29 [In reply to]

snacktime wrote:
> Before I spend a whole lot of time on this I'm curious if someone else
> has run across this. This is mod perl 1.29.
>
> We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
> 5.8.7. This included reinstalling around 50 perl modules (some to new
> versions) from the freebsd ports. Ever since the upgrade, apache
> increases in memory by about a third of it's original size whenever by
> it restarts via SIGHUP.
>
> Does this ring a bell for anyone, or do I start debugging from scratch?

http://perl.apache.org/docs/1.0/guide/troubleshooting.html#httpd_keeps_on_growing_after_each_restart

--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas [at] stason http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com


gozer at ectoplasm

Jul 20, 2005, 11:19 AM

Post #3 of 8 (697 views)
Permalink
Re: memory leak with perl5.8/freebsd/mod_perl 1.29 [In reply to]

snacktime wrote:
> Before I spend a whole lot of time on this I'm curious if someone else
> has run across this. This is mod perl 1.29.
>
> We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
> 5.8.7. This included reinstalling around 50 perl modules (some to new
> versions) from the freebsd ports. Ever since the upgrade, apache
> increases in memory by about a third of it's original size whenever by
> it restarts via SIGHUP.
>
> Does this ring a bell for anyone, or do I start debugging from scratch?

I've encouontered this problem before on FreeBSD and have had some success
working around it. One of the main problems seems to be with FreeBSD's Perl
build picking Perl's malloc instead of the native FreeBSD malloc(). You can see
how your perl is configured like this:

$> perl -V:usemymalloc
usemymalloc='y';

And if it's the case, my recommendation would be to rebuild your perl with the
system malloc() and see if this problem goes away.

--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Attachments: signature.asc (0.25 KB)


pgollucci at p6m7g8

Jul 20, 2005, 11:36 AM

Post #4 of 8 (694 views)
Permalink
Re: memory leak with perl5.8/freebsd/mod_perl 1.29 [In reply to]

Philippe M. Chiasson wrote:

>I've encouontered this problem before on FreeBSD and have had some success
>working around it. One of the main problems seems to be with FreeBSD's Perl
>build picking Perl's malloc instead of the native FreeBSD malloc(). You can see
>how your perl is configured like this:
>
>$> perl -V:usemymalloc
>usemymalloc='y';
>
>
The default /usr/port/lang/perl5.8
does build perl with this flag. At least on 5.4 and 6.0-current.

pgollucci [at] smgella /home/pgollucci rv=0 5 >uname
FreeBSD smgellar 5.4-RELEASE i386

pgollucci [at] smgella /home/pgollucci rv=0 4 >/usr/local/bin/perl
-V:usemymalloc
usemymalloc='y';

I may be able to nudge ports@ to change add a flag to Makefile.

--
END
---------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci (pgollucci [at] p6m7g8) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com


gozer at ectoplasm

Jul 20, 2005, 12:03 PM

Post #5 of 8 (698 views)
Permalink
Re: memory leak with perl5.8/freebsd/mod_perl 1.29 [In reply to]

Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>
>> I've encouontered this problem before on FreeBSD and have had some
>> success
>> working around it. One of the main problems seems to be with FreeBSD's
>> Perl
>> build picking Perl's malloc instead of the native FreeBSD malloc().
>> You can see
>> how your perl is configured like this:
>>
>> $> perl -V:usemymalloc
>> usemymalloc='y';
>>
> The default /usr/port/lang/perl5.8
> does build perl with this flag. At least on 5.4 and 6.0-current.
>
> pgollucci [at] smgella /home/pgollucci rv=0 5 >uname
> FreeBSD smgellar 5.4-RELEASE i386
>
> pgollucci [at] smgella /home/pgollucci rv=0 4 >/usr/local/bin/perl
> -V:usemymalloc
> usemymalloc='y';
>
> I may be able to nudge ports@ to change add a flag to Makefile.

I remember reading a thread on ports@ about the reason why that flag was
added in the first ( can't find the thread right now ), but I seem to recall
there was some problem with Perl's usage of FreeBSD's malloc() causing some
performance problem. I believe that problem went away at some point but the
workaround remained.

Poking ports [at] freebsd about this issue could possibly help, especially if
the reason this was done can be shown not to apply anymore.

--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Attachments: signature.asc (0.25 KB)


pgollucci at p6m7g8

Jul 20, 2005, 12:17 PM

Post #6 of 8 (675 views)
Permalink
Re: memory leak with perl5.8/freebsd/mod_perl 1.29 [In reply to]

Philippe M. Chiasson wrote:

>Philip M. Gollucci wrote:
>
>
>>Philippe M. Chiasson wrote:
>>
>>
>Poking ports [at] freebsd about this issue could possibly help, especially if
>the reason this was done can be shown not to apply anymore.
>
>
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/Makefile

rev 1.61
rev 1.49
rev 1.40



END
---------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci (pgollucci [at] p6m7g8) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com


gozer at ectoplasm

Jul 20, 2005, 12:35 PM

Post #7 of 8 (675 views)
Permalink
Re: memory leak with perl5.8/freebsd/mod_perl 1.29 [In reply to]

Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>> Philip M. Gollucci wrote:
>>> Philippe M. Chiasson wrote:
>>>
>> Poking ports [at] freebsd about this issue could possibly help,
>> especially if
>> the reason this was done can be shown not to apply anymore.
>>
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/Makefile
>
> rev 1.61

"Switch to perlmalloc by
default, unless threaded perl is built, to improve performance."

> rev 1.49

"WITH_PERL_MALLOC - to compile with perl's own malloc, as opposed to
the freebsd system malloc. Some might find this useful, since perl's
malloc is marginally faster in typical cases, and orders of
magnitude faster in degenerate cases. Use with care."

Guess this does show the main reason for this is a performance problem with
Perl's usage of FreeBSD's malloc(). But I'd be curious to see if this
performance problem is still a problem. And if it still is a problem, maybe
there is something Perl isn't doing quite right.

In any case, getting to the bottom of this issue sure sounds interesting.

In the meantime, FreeBSD'ers that have growing problems on FreeBSD should
consider building their ports Perl with WITH_PERL_MALLOC=no

--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Attachments: signature.asc (0.25 KB)


snacktime at gmail

Jul 20, 2005, 3:57 PM

Post #8 of 8 (683 views)
Permalink
Re: memory leak with perl5.8/freebsd/mod_perl 1.29 [In reply to]

> > rev 1.61
>
> "Switch to perlmalloc by
> default, unless threaded perl is built, to improve performance."
>
> > rev 1.49
>
> "WITH_PERL_MALLOC - to compile with perl's own malloc, as opposed to
> the freebsd system malloc. Some might find this useful, since perl's
> malloc is marginally faster in typical cases, and orders of
> magnitude faster in degenerate cases. Use with care."
>
> Guess this does show the main reason for this is a performance problem with
> Perl's usage of FreeBSD's malloc(). But I'd be curious to see if this
> performance problem is still a problem. And if it still is a problem, maybe
> there is something Perl isn't doing quite right.
>
> In any case, getting to the bottom of this issue sure sounds interesting.
>
> In the meantime, FreeBSD'ers that have growing problems on FreeBSD should
> consider building their ports Perl with WITH_PERL_MALLOC=no
>

That's a requirement btw if you are using perl 5.6.x on Freebsd and
build mod perl from ports. The default build of perl 5.6.x on freebsd
is incompatible with the mod perl port because the perl malloc causes
a segfault when mod perl is built as a dso. The mod perl port gives a
warning about it though.

Chris

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.