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:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|