httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From harish kulkarni <wasinap...@gmail.com>
Subject Re: Major memory leak, advice diagnosing
Date Thu, 28 Oct 2010 09:49:31 GMT
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 <ezyang@mit.edu> 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
>

Mime
View raw message