You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Kent, Mr. John" <ke...@nrlmry.navy.mil> on 2002/07/10 02:04:31 UTC
Growing Server Size modperl-2.0 on Solaris 2.7
Greetings,
Have noticed that modperl-2.0 servers running on Solaris 2.7 start
off at 23M in size. Five hours later they were at 38M. If allowed to
continue
they could eventually use up all available RAM and crash the system.
Stopping then restarting returned them to 23M.
Has anyone else encountered this and is there a recommended solution
other than periodically stopping and starting?
Thank you,
John Kent
Webmaster
Naval Research Laboratory
Monterey CA
http://kauai.nrlmry.navy.mil/sat_products.html
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Stas Bekman wrote:
>
>> I think the idea was to have a special thread running whose only purpose
>> is monitoring the pool of idle interpreters.
>
>
> That sounds like a better solution.
The drawback is that there will be two different solutions for threaded
and preforked mpms, meaning harder to do transitions.
>> I believe that we can add a Perl space hook that sets a flag that
>> condemns an interpreter to death.
>
>
> The other problem, which might be harder, is to figure out how big a
> particular interpreter is. The current implementations of
> Apache::SizeLimit and GTopLimit cheat by asking the OS how big the
> current process is. That won't work with threads.
B::Size and B::TerseSize?
Since the check can be run on the idle servers that shouldn't be a
problem if they are slow. On the other hand since the idea is to always
re-use the recently used interpreters, I'm not sure when there will be a
chance to run checks on the interpreters on the top of the pool. Need to
test how fast B::Size to decide whether it's feasible to run the check
during the phase when the interpreter is being returned to the pool.
Also it could be that we will need various schemes for pool management
and for certain servers a round-robin solution will be more memory
effective if we figure out that the interpreter memory usage measuring
is slow and can be done only on the idle interpreters in the pool,
because in that way fat interpreters can be killed.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> I think the idea was to have a special thread running whose only purpose
> is monitoring the pool of idle interpreters.
That sounds like a better solution.
> I believe that we can add a Perl space hook that sets a flag that
> condemns an interpreter to death.
The other problem, which might be harder, is to figure out how big a
particular interpreter is. The current implementations of
Apache::SizeLimit and GTopLimit cheat by asking the OS how big the
current process is. That won't work with threads.
- Perrin
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Stas Bekman wrote:
>
>> If you are talking about threaded mpms, we will need to develop new
>> tools to restrict the size of the perl interpreters in the pool.
>
>
> I was thinking about that too. Are there hooks for causing an
> interpreter to exit? Is it safe to simply call CORE::exit? I'd like
> to make SizeLimit work for the threaded MPMs if possible.
I think the idea was to have a special thread running whose only purpose
is monitoring the pool of idle interpreters. Inside that thread you
could have various processes happening for each process:
- garbage collection (walk the optree and free big chunks of
reserved/unused memory, other optimizations)
- destroy interpreters that have too much non-shared memory, etc
- reload modified modules?
- etc..
I think this was somewhat discussed about a year ago.
I'm not sure if this approach can be somehow piggy-backed into
Apache::SizeLimit so users will be able to run pretty much the same
setup for threaded and non-threaded mpms.
I believe that we can add a Perl space hook that sets a flag that
condemns an interpreter to death. When an interpreter is put back into
the pool, this flag can be checked and modperl_interp_cleanup() called
if that flag is set, thus killing the interpreter.
I'm not sure if CORE::exit will work, most likely not, because it'll
probably unsync the pool state. Need to try though.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> If you are talking about threaded mpms, we will need to develop new
> tools to restrict the size of the perl interpreters in the pool.
I was thinking about that too. Are there hooks for causing an
interpreter to exit? Is it safe to simply call CORE::exit? I'd like to
make SizeLimit work for the threaded MPMs if possible.
- Perrin
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Posted by Stas Bekman <st...@stason.org>.
Kent, Mr. John wrote:
> Greetings,
>
> Have noticed that modperl-2.0 servers running on Solaris 2.7 start
> off at 23M in size. Five hours later they were at 38M. If allowed to
> continue
> they could eventually use up all available RAM and crash the system.
>
> Stopping then restarting returned them to 23M.
>
> Has anyone else encountered this and is there a recommended solution
> other than periodically stopping and starting?
Are you using the prefork mpm or a threaded one? If this is a prefork,
use Apache::SizeLimit (or Apache::GTopLimit) just like in 1.0. See:
http://perl.apache.org/release/docs/1.0/guide/performance.html#Preventing_Your_Processes_from_Growing
If you are talking about threaded mpms, we will need to develop new
tools to restrict the size of the perl interpreters in the pool.
Other than try to figure out if your code (or the server) doesn't leak.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Growing Server Size modperl-2.0 on Solaris 2.7
Posted by stevea <st...@nwtechops.com>.
>Greetings,
>Have noticed that modperl-2.0 servers running on Solaris 2.7 start
>off at 23M in size. Five hours later they were at 38M. If allowed to
>continue
>they could eventually use up all available RAM and crash the system.
>Stopping then restarting returned them to 23M.
>Has anyone else encountered this and is there a recommended solution
>other than periodically stopping and starting?
Hey John,
I don't see that on my Solaris 8 box (unless I throw some weak code at it).
BTW: There was a reason Sun created 8. ;)