** Using WeBWorK **

I think one origin of the memory leak may be that a persistent perl interpreter
does not do garbage collection on its parse tree, only on its data structures.
Processing problems requires parsing their perl code, so the parse tree
would grow monotonically.

For Apache 1, one can use the perl module Apache::SizeLimit to kill automatically
Apache child processes when they reach a prescribed size. Then one doesn't have
to restart Apache in order to reclaim leaked memory.

Sincerely,

Bill Wheeler, Indiana University Bloomington

Dear Rich,

Sometimes this problem arises because the "Refresh"
function on some operating systems and browser combinations
is a repeating key, so that a student who accidentally holds
down the F5 key (e.g., by resting a textbook on the keyboard)
can generate so many requests (6-10 per second) that the server
and Apache can't handle the load. In such cases, RAM is quickly
exhausted and swapping begins, which is untenable.

When using Apache 1, the solution involves using
Apache::SizeLimit and httpd.conf to limit
the size and number of Apache children.

Then WeBWorK can survive, but users will experience
a brief period of reduced service until the unintended
denial of service attack ends.

Your server (Pentium 3 Xeon, 512 MB RAM) may be a bit weak for a WeBWorK server.
We have 5-8 GB RAM on ours here at IU Bloomington.

Sincerely,

Bill Wheeler