Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

11.2. Setting the MaxRequestsPerChild Directive

The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child process can handle during its lifetime. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is zero, the process will live until the server kills it (because it is no longer needed, which will depend on the value of MinSpareServers and the number of current requests) or until the server itself is stopped.

Setting MaxRequestsPerChild to a non-zero limit solves some memory-leakage problems caused by sloppy programming practices and bugs, whereby a child process consumes a little more memory after each request. In such cases, and where the directive is left unbounded, after a certain number of requests the children will use up all the available memory and the server will die from memory starvation. Note that sometimes standard system libraries leak memory too, especially on operating systems with bad memory management.

If this is your situation you may want to set MaxRequestsPerChild to a small number. This will allow the system to reclaim the memory that a greedy child process has consumed when it exits after MaxRequestsPerChild requests.

But beware—if you set this number too low, you will lose some of the speed bonus you get from mod_perl. Consider using Apache::PerlRun if the leakage is in the CGI script that you run. This handler flushes all the memory used by the script after each request. It does, however, reduce performance, since the script's code will be loaded and recompiled for each request, so you may want to compare the loss in performance caused by Apache::PerlRun with the loss caused by memory leaks and accept the lesser of the evils.

Another approach is to use the memory usage-limiting modules, Apache::SizeLimit or Apache::GTopLimit. If you use either of these modules, you shouldn't need to set MaxRequestPerChild (i.e., you can set it to 0), although for some developers, using both in combination does the job. These modules also allow you to control the maximum unshared and minimum shared memory sizes. We discuss these modules in Chapter 14.



Copyright © 2003 O'Reilly & Associates. All rights reserved.


 
 
  Published courtesy of O'Reilly Design by Interspire