Re^2: Catalyst/FastCGI and Perpetually Growing Perl Processes

Is it necessarily a memory leak though? It seems possible it's just a side effect of having a very long-running Perl process that's never going to release memory back to the system. mod_perl/Apache seem to anticipate this by having each web process only serve X requests before being re-spawned, re-starting the memory pool from scratch.

Comment on Re^2: Catalyst/FastCGI and Perpetually Growing Perl Processes

Replies are listed 'Best First'.
Re^3: Catalyst/FastCGI and Perpetually Growing Perl Processes by Anonymous Monk on Oct 15, 2012 at 23:44 UTC
Is it necessarily a memory leak though? yes, unintended memory growth is always a leak It seems possible it's just a side effect of having a very long-running Perl process that's never going to release memory back to the system. While that is possible (operating system memory managers are tricky) it is very unlikely. With proper scoping the memory should be stable, it might peak during requests, but it should stabilize. If it doesn't, and you didn't code a giant %CACHE hash, then it is definitely a leak (unintended memory growth). See Re^3: Scope of lexical variables in the main script for some links/discussion	[reply]

Replies are listed 'Best First'.

Re^3: Catalyst/FastCGI and Perpetually Growing Perl Processes
by Anonymous Monk on Oct 15, 2012 at 23:44 UTC

Is it necessarily a memory leak though?

yes, unintended memory growth is always a leak

It seems possible it's just a side effect of having a very long-running Perl process that's never going to release memory back to the system.

While that is possible (operating system memory managers are tricky) it is very unlikely. With proper scoping the memory should be stable, it might peak during requests, but it should stabilize.

If it doesn't, and you didn't code a giant %CACHE hash, then it is definitely a leak (unintended memory growth). See Re^3: Scope of lexical variables in the main script for some links/discussion

[reply]