Dany Ayotte wrote:
Hello

I have written a large web service application entirely written in Perl, build as Apache::Registry under mod_perl-1.99_11 build with perl 5.8.0 under Apache 2.0.47, all compile with Microsoft visual C++ 6.0.

The same application run fine without too much memory leak on Linux (Apacge 1.3.x, mod_perl 1.27, perl 5.8.0) and Apple Mac OS/X, even on Solaris 8.0.

On Windows, that's another story. Each connection to Apache, the Apache process clone himself and double the amount of memory required to run.

It probably doesn't double, but adds the size of one thread.


Worst, the memory is never released back to the OS until the Apache service is restart or until the computer is put on his knees. What's going wrong? I did not want to use Apache 1.x on Windows because of the threading issue.

Yes, but once the cloned perl interpreter has finished serving the request it's available for the next request. So it's not ever growing. Say you have at most 10 concurrent requests to modperl. You will need only 10 perl interpreters to satisfy them.


It look like a threading issue related to perl. I have a very small perl program which create thread and each thread created double the amount of memory required by the program. Does anybody have any clues?

If you can reproduce the problem with plain perl, there is no surprise you can see it with mod_perl. perl ithreads clone all the mutables data, and share only the OpCode tree (if it was preloaded at the server startup). So depending on whether you have a lot of mutable data or not, you will have more or less memory used.


Unfortunately threads don't benefit from forked process memory sharing, because they are designed to share everything created before they were spawned (Which is even better than forked sharing). But perl ithreads are a totally different beast. I believe they were implemented this way to make it easier for users, you don't have to worry about your variables when you run a program under threads. Of course memory is a bit of an issue here. So does the slowness of the perl_clone() (which is the function used to clone new interpreters).

So for some applications threaded perl/modperl will be a good choice, for others won't. Too bad win32 has no options and stuck with threads. On Unix we have the good old prefork mpm for the kind of apps with a lot of mutable data, and the worker mpm for apps benefitting from threads.

__________________________________________________________________
Stas Bekman            JAm_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


-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html



Reply via email to