| WeBWorK2 here at Indiana does leak memory slowly.
So we keep the MaxRequestsPerChild at no more than 100.
However, under heavy loads, this may not be sufficient,
because Apache "requests" and WeBWorK "requests" are different.
If the Apache configuration directive KeepAlive is set
to On (as recommended in the Apache documenation), then
the number of Apache requests for an Apache child is
the number of connections that the child has handled.
So if one sets the Apache configuration directives to
MaxRequestsPerChild 100
KeepAlive On
KeepAliveTimeOut 30
MaxKeepAliveRequests 10
then an Apache Child might handle up to
MaxRequestsPerChild * MaxKeepAliveRequests = 100 * 10 = 1000
WeBWorK requests before it dies. The point is that
if a student makes successive submissions in less than
KeepAliveTimeOut seconds, then all of the submissions count as
only one request and the processing will go on until
the MaxKeepAliveRequests limit is reached.
Although it's uncommon for students in science calculus
courses (e.g., Stewart's Single Variable textbooks) to submit
answers rapidly one after another,
it's fairly common here for some students in finite math
and business calculus courses to submit answers
rapidly one after another in an effort to "guess" the
right answer. For instance, I've observed students, who
are frustrated with counting problems, to submit
the numbers 10, 11, 12, 13, 14, 15, 16, ...
one after another at a rate of one per five seconds
in an effort to guess the answers to questions.
I have WeBWorK2 record in its timing log the number
of WeBWorK requests an Apache child has processed
every time the child processes a WeBWorK request.
Even though MaxRequestsPerChild=100 , I have seen
counts of 200-300 WeBWorK requests processed by
still active Apache children.
But one cannot just clamp down on MaxNumberOfRequests and
MaxKeepAliveRequests in order to hold down memory leakage.
In tuning a WeBWorK server, one has to
find a balance between memory utilization, the average
size of the Apache children (i.e., how much
memory leakage to tolerate), the number of Apache
children, and the average number of WeBWorK requests
processed by Apache children during their lifetimes.
Creating a new Apache child uses up a significant amount
of time relative to the time required to process
a WeBWorK request. During periods of peak loading here,
our servers run at 80-100 % utilization with
loads factors of 1.0-3.5 and 3-6 webwork requests per second
for sustained periods of time. We cannot afford the overhead of frequently creating new Apache children. Fortunately,
our servers have 4-8 GB of RAM, so we can tolerate a certain
amount of memory leakage.
One additional technique that we use to minimize memory leakage
is to route course administration requests to a separate Apache
server that runs on the same computer but listens to a different port.
The reason is that the course administration functions can
consume a lot of RAM for large WeBWorK courses. (Some
of our WeBWorK courses have 500-600 students in them.)
Some of these courses assign homework for every class meeting,
for a total of 25-30 assignments per semester. By the end
of the semester, a single invocation of a course
administration function can generate a memory leak of
30-50 megabytes. (In WeBWorK1, I even observed memory
leaks of more than 100 megabytes just from calling
the Professor's page.) Needless to say, we keep the
Apache course administration server on an austere diet.
Sincerely,
Bill Wheeler, Indiana University, Bloomington
<| Post or View Comments |>
|