The sharing of memory is a very important factor. If your OS supports it (and most sane systems do), a lot of memory can be saved by sharing it between child processes. This is possible only when code is preloaded at server startup. However, during a child process's life, its memory pages tend to become unshared. Here is why.
There is no way to make Perl allocate memory so that (dynamic) variables land on different memory pages from constants or the rest of your code (which is really just data to the Perl interpreter), so the copy-on-write effect (explained in a moment) will hit almost at random.
If many modules are preloaded, you can trade off the memory that stays shared against the time for an occasional fork of a new Apache child by tuning the MaxRequestsPerChild Apache directive. Each time a child reaches this upper limit and dies, it will release its unshared pages. The new child will have to be forked, but it will share its fresh pages until it writes on them (when some variable gets modified).
The ideal is a point where processes usually restart before too much memory becomes unshared. You should take some measurements, to see if it makes a real difference and to find the range of reasonable values. If you have success with this tuning, bear in mind that the value of MaxRequestsPerChild will probably be specific to your situation and may change with changing circumstances.
It is very important to understand that the goal is not necessarily to have the highest MaxRequestsPerChild that you can. Having a child serve 300 requests on precompiled code is already a huge overall speedup. If this value also provides a substantial memory saving, that benefit may outweigh using a higher MaxRequestsPerChild value.
A newly forked child inherits the Perl interpreter from its parent. If most of the Perl code is preloaded at server startup, then most of this preloaded code is inherited from the parent process too. Because of this, less RAM has to be written to create the process, so it is ready to serve requests very quickly.
During the life of the child, its memory pages (which aren't really its own to start with—it uses the parent's pages) gradually get dirty—variables that were originally inherited and shared are updated or modified—and copy-on-write happens. This reduces the number of shared memory pages, thus increasing the memory requirement. Killing the child and spawning a new one allows the new child to use the pristine shared memory of the parent process.
The recommendation is that MaxRequestsPerChildshould not be too large, or you will lose some of the benefit of sharing memory. With memory sharing in place, you can run many more servers than without it. In Chapter 11 we will devise a formula to calculate the optimum value for the MaxClients directive when sharing is taking place.
As we mentioned in Chapter 9, you can find the size of the shared memory by using the ps(1) or top(1) utilities, or by using the GTop module:
use GTop ( ); print "Shared memory of the current process: ", GTop->new->proc_mem($$)->share, "\n"; print "Total shared memory: ", GTop->new->mem->share, "\n";
Eric Cholet (Logilune) and
Stas Bekman (StasoSphere & Free Books).