huge apache+mod_perl processes

huge apache+mod_perl processes

am 28.09.2010 11:16:41 von Eugene Toropov

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01CB5F0F.6427F700
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

Greetings,

We have a problem with huge Apache+mod_perl2 processes of 150-200 Mb in =
size. After apache restart they are usually 40-50 Mb in size, then in a =
minute grow up to 100-150 Mb and then some time later may grow up to 200 =
Mb. I suspect a certain type of http queries and would like to know if =
there are any manuals/howtos/tools to investiagate such cases.

# perl -v
This is perl, v5.10.1 (*) built for x86_64-linux

# strings /usr/local/apache2/modules/mod_perl.so | grep mod_perl\/
mod_perl/2.0.4

# /usr/local/apache2/bin/httpd -v
Server version: Apache/2.2.14 (Unix)

# pmap -x 8320
8320: /usr/local/apache2/bin/httpd -DSSL
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 584 496 0 r-x-- httpd
0000000000692000 24 20 20 rw--- httpd
0000000000698000 12 8 8 rw--- [ anon ]
0000000017c10000 147640 144612 144608 rw--- [ anon ]
.....
---------------- ------ ------ ------
total kB 352380 156560 151324


# /usr/local/apache2/bin/httpd -l
Compiled in modules:
core.c
mod_authn_file.c
mod_authn_default.c
mod_authz_host.c
mod_authz_groupfile.c
mod_authz_user.c
mod_authz_default.c
mod_auth_basic.c
mod_include.c
mod_filter.c
mod_log_config.c
mod_env.c
mod_setenvif.c
mod_version.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_cgi.c
mod_negotiation.c
mod_dir.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_so.c
#


Cheers
Eugene
------=_NextPart_000_0040_01CB5F0F.6427F700
Content-Type: text/html;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable








Greetings,

 

We have a problem with huge =
Apache+mod_perl2=20
processes of 150-200 Mb in size. After apache restart they are usually =
40-50 Mb=20
in size, then in a minute grow up to 100-150 Mb and then some time =
later=20
may grow up to 200 Mb. I suspect a certain type of http queries and =
would=20
like to know if there are any manuals/howtos/tools to investiagate such=20
cases.

 

# perl -v

This is perl, v5.10.1 (*) built for=20
x86_64-linux

# strings =
/usr/local/apache2/modules/mod_perl.so |=20
grep mod_perl\/
mod_perl/2.0.4

# /usr/local/apache2/bin/httpd =
-v
Server=20
version: Apache/2.2.14 (Unix)

 

# pmap -x 8320

8320:   =
/usr/local/apache2/bin/httpd=20
-DSSL
Address         &nb=
sp;=20
Kbytes     RSS   Dirty Mode  =20
Mapping
0000000000400000     =
584    =20
496       0 r-x-- =20
httpd
0000000000692000     =20
24      20      20 =
rw--- =20
httpd
0000000000698000     =20
12       =
8       8=20
rw---    [ anon ]
0000000017c10000  147640 =20
144612  144608 rw---    [ anon =
]
....

----------------  ------  =
------ =20
------
total kB          =

352380  156560  151324

 

# /usr/local/apache2/bin/httpd =
-l
Compiled in=20
modules:
  core.c
  mod_authn_file.c
 =20
mod_authn_default.c
  mod_authz_host.c
 =20
mod_authz_groupfile.c
  mod_authz_user.c
 =20
mod_authz_default.c
  mod_auth_basic.c
  =
mod_include.c
 =20
mod_filter.c
  mod_log_config.c
  mod_env.c
 =20
mod_setenvif.c
  mod_version.c
  prefork.c
 =20
http_core.c
  mod_mime.c
  mod_status.c
 =20
mod_autoindex.c
  mod_asis.c
  mod_cgi.c
 =20
mod_negotiation.c
  mod_dir.c
  mod_actions.c
 =20
mod_userdir.c
  mod_alias.c
  mod_rewrite.c
 =20
mod_so.c
#



Cheers

Eugene


------=_NextPart_000_0040_01CB5F0F.6427F700--

Re: huge apache+mod_perl processes

am 04.10.2010 20:13:46 von Michael Ludwig

Hi Eugene,

Eugene Toropov schrieb am 28.09.2010 um 13:16 (+0400):
>
> We have a problem with huge Apache+mod_perl2 processes of 150-200 Mb
> in size. After apache restart they are usually 40-50 Mb in size, then
> in a minute grow up to 100-150 Mb and then some time later may grow up
> to 200 Mb. I suspect a certain type of http queries and would like to
> know if there are any manuals/howtos/tools to investiagate such cases.

I don't know of any master tool to pinpoint the resource hog, but it
might help to think about what kind of potentially memory-hungry things
your application does.

* accumulating data in memory
* large XML docs read into memory
* SQL data not using an iterator, but accumulating in memory
* large file uploads
* ...

Are you able to reproduce the issue in your dev environment (where I
presume clicks are under control)? Then you might be able to determine
the handler that gobbles up memory.

I've also seen situations (with bad code) where memory consumption
depended on the data available for a process to read.

Hope this helps.
--
Michael Ludwig