hello, apache used apr mem management apis.. and there are pools formed for each conn, request.... out of the global pool which never gets freed. ( from my earlier apache knowledge.. i hope this persists even today).
it's little hard to track where and why the pool sizes increasing.. one possiblity is in case as part of implementation someone while handling request.. ends up using connection pool for memory allocation or global pool for memory allocation we might see memory leaks. none of the profilers or valgrind can track this. so best approach would be to understand apr and apache memory management. we had fixed a similar issue.. way back.. just use the following link, hope it helps. http://harishvk27.wordpress.com/category/techy/apache/ -thanks,regards harish On Thu, Oct 28, 2010 at 4:20 AM, Edward Z. Yang <[email protected]> wrote: > Hello all, > > We've observed that our httpd.workers on Fedora 13 have been leaking some > major > amounts of memory: > > 7343 apache 20 0 2560m 1.1g 3940 S 35.1 28.6 21:06.49 httpd.worker > > Unfortunately, we don't have much more information than that (and > the fact that the httpd.workers refuse to die when we shut down the server > with 'service httpd stop'. > > What kind of diagnostic information would help this list debug this problem? > Here are our versions: > > httpd 2.2.16 with some custom patches [1] > Loaded Modules: > core_module (static) > mpm_worker_module (static) > http_module (static) > so_module (static) > auth_basic_module (shared) > auth_digest_module (shared) > authn_file_module (shared) > authn_alias_module (shared) > authn_anon_module (shared) > authn_default_module (shared) > authz_host_module (shared) > authz_user_module (shared) > authz_owner_module (shared) > authz_groupfile_module (shared) > authz_default_module (shared) > ldap_module (shared) > include_module (shared) > log_config_module (shared) > env_module (shared) > ext_filter_module (shared) > expires_module (shared) > deflate_module (shared) > headers_module (shared) > setenvif_module (shared) > mime_module (shared) > status_module (shared) > autoindex_module (shared) > negotiation_module (shared) > dir_module (shared) > actions_module (shared) > userdir_module (shared) > alias_module (shared) > rewrite_module (shared) > proxy_module (shared) > proxy_http_module (shared) > suexec_module (shared) > cgi_module (shared) > ssl_module (shared) > vhost_ldap_module (shared) > fcgid_module (shared) > auth_sslcert_module (shared) > authz_afsgroup_module (shared) > auth_optional_module (shared) > > Before you go and blame the patches, note that we've been running them > since Fedora 11 and did not see any memory leakage. We semi-vaguely > suspect mod_fcgid to be the problem (we're running an fc12 RPM to > work around performance problems with the latest version), but haven't > rigorously tested this theory yet. > > [1] http://scripts.mit.edu/trac/browser/trunk/server/common/patches >
