httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Sean Conner)
Subject Re: [users@httpd] Serious Memory Leak Problem
Date Fri, 21 Oct 2005 19:04:37 GMT
It was thus said that the Great Marc Perkel once stated:
> I've asked about this before and never got an answer. I used to run my 
> server on a dual xeon computer and it was very memory efficient. I moved 
> to the 64 bit version of of Fedora Core 4 and now it's filling up memory 
> really fast.
> Both servers had 4 gigs of ram. And basically the same configuration 
> file using the same modules for both. It is especially bad where perl is 
> involved.
> Now I have to set MaxRequestsPerChild to no more than 10 to keep ram 
> from filling up.  The server is rather busy serving 67 requests per 
> second.  If I set MaxRequestsPerChild to 30 - it quickly fills up 
> another gig of ram.
> I really need to fix this. Sure could use some help on trying to figure 
> out where the problem is.

  Don't know how much you know about programming, but a 64-bit architecture
is twice the size of a 32-bit architecture (obviously).  The impact is that
some fundamental data types used in programming are now twice as big.  For
instance, given the following definition of some data used in Apache (pulled
from 2.0.53 and reformatted):

	typedef struct {
	    char                *d;
	    unsigned             d_components;
	    allow_options_t      opts;
	    allow_options_t      opts_add;
	    allow_options_t      opts_remove;
	    overrides_t          override;
	    char                *ap_default_type;
	    int                 *satisfy;
	    char                *ap_auth_type;
	    char                *ap_auth_name;
	    apr_array_header_t  *ap_requires;
	    char               **response_code_strings; 
	    unsigned int         hostname_lookups : 4;
	    signed int           do_rfc1413 : 2;   
	    signed int           content_md5 : 2; 
	    unsigned             use_canonical_name : 2;
	    unsigned             d_is_fnmatch : 1;
	    unsigned             add_default_charset : 2;
	    const char          *add_default_charset_name;
	    struct rlimit       *limit_cpu;
	    apr_off_t            limit_req_body;  
	    long                 limit_xml_body;      
	    server_signature_e   server_signature;
	    int                  loglevel;
	    apr_array_header_t  *sec_file;
	    regex_t             *r;
	    const char          *mime_type;   
	    const char          *handler;    
	    const char          *output_filters;
	    const char          *input_filters;
	    int                  accept_path_info;    
	    apr_hash_t          *ct_output_filters;
	    etag_components_t    etag_bits;
	    etag_components_t    etag_add;
	    etag_components_t    etag_remove;
	    unsigned int         enable_mmap : 2;
	    unsigned int         enable_sendfile : 2;
	    unsigned int         allow_encoded_slashes : 1;
	} core_dir_config;

  Most of these fields are 4 bytes in size on a 32-bit system (any line with
a '*' in it---perhaps some others but I would have to look up their
definitions to find out but for this discussion, that really isn't
necessary) while on a 64-bit system these are now 8 bytes in size.  And this
particular structure is used (I suspect, given its name) for each
<Directory> specified in the configuration file.  

  And it's not only data, but code too, may be up to twice the size from a
32-bit version.  Yes, there are some advantages (mainly related to how much
memory can be addressed) to using a 64-bit system, but for the most part,
web serving isn't going to take much advantage of a 64-bit system.

  If the memory usage is that much of an issue, perhaps you should think of
going back to a 32-bit system if it worked fine for you (I'm of the "if it
ain't broke, don't fix it" camp myself and will never upgrade just for
upgrading sake).  

  -spc (32-bit seems to be a sweet spot for general computing)

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message