I think the problem is that the application is leaking memory somehow through the Perl interpreter (the application compiled without Perl does not increase its memory usage so obviously).
Perl uses reference counting and automatic garbage collection, so one of the most common sources of leaks are circular references. That is, if $a is a reference to $b, $b is a reference to $c, and $c is a reference to $a, then normal garbage collection will never be able to release $a, $b, or $c until the circle is broken.
Another common problem is constantly-growing hash tables and/or arrays. If you're storing session information in a hash table, and forgetting to delete the hash entry when the session ends, that has table will keep growing indefinitely. (It's also a minor security risk, if there is any possibility that session keys can get re-used.)
. try and understand how mod_perl is organised and look for explicit tactics it uses to minimise leaks
Very few coding tactics - it's very, very easy to write a leaky mod_perl app.
What many administrators do is use a separate mod_perl server on a high port, using the main port 80 server as a proxy. The mod_perl server can then be tuned separately from the main server, and is often configured to recycle child processes after a lower number of requests than would be necessary when serving static content and/or traditional CGIs.
sherm--
If you listen to a UNIX shell, can you hear the C?
