Re: Growing Server Size modperl-2.0 on Solaris 2.7
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 BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] 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
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
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 BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] 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
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
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 BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] 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
>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. ;)