Hmm,
I can't agree with your opinion.
The thing is here, that when the apache server is shutdown and
restarted the memory is not freed and so the httpd processes get the
out of memory errors much more quickly because the amount of free
memory is much lower.
About the fact that stopping Apache doesnt free the memory, I wanted to
point out that our sysadmin told us this is due to how Apache manages
memory.
We didnt went into the details so I cant tell you more.
Should search the documentation.
Anyway this shouldnt be related to the problem that causes the memory
leak.
Adrian Marsh ha scritto:
Hi Christian,
Do you think you could ask them to see if they resolved it?
I had similar thoughts, so in my VMware copy I tried various things, including working without SSL, but I didn't see the results get any better.
Adrian
-----Original Message-----
From: Domsch, Christian (IZLBW Extern) [mailto:christian.domsch@xxxxxxxxx]
Sent: 03 April 2009 14:23
To: users@xxxxxxxxxxxxxxxx
Subject: AW: Apache memory hog
Hello.
A client of our company has similar issues. They run SLES 10 with apache 2.2.x and the newest subversion 1.5.x and also use https. For authentication they use winbind and not ldap.
They too have the problem, that the apache processes take up a lot of cpu cycles and use up the ram to the point, where the processes crash with out ouf memory. After that the memory is not freed. Even when the httpd processes are stopped (and not crash) the memory is not freed.
I do not know the fine details here, bit the sysadmin found some odd things going on with ssl.
-----Ursprüngliche Nachricht-----
Von: Tom Evans [mailto:tevans.uk@xxxxxxxxxxxxxx]
Gesendet: Freitag, 3. April 2009 15:16
An: users@xxxxxxxxxxxxxxxx
Cc: aw@xxxxxxxxxx
Betreff: RE: Apache memory hog
On Fri, 2009-04-03 at 13:58 +0100, Adrian Marsh wrote:
Hi Andre,
Thanks for the reply. No its definitely the httpd process. I see each thread consuming hundreds of megs of RES memory being used in TOP. I just restarted it and already each is consuming:
10006 apache 15 0 279m 15m 3160 S 0.0 0.1 0:00.29 httpd
10004 apache 15 0 278m 13m 3400 S 0.0 0.1 0:00.05 httpd
10007 apache 15 0 278m 13m 3048 S 0.0 0.1 0:00.04 httpd
10001 apache 15 0 277m 13m 3456 S 0.0 0.1 0:00.08 httpd
10003 apache 15 0 277m 13m 2976 S 0.0 0.1 0:00.10 httpd
10002 apache 15 0 277m 13m 3112 S 0.0 0.1 0:00.07 httpd
10005 apache 15 0 277m 13m 3080 S 0.0 0.1 0:00.06 httpd
10000 apache 15 0 277m 12m 3432 S 0.0 0.1 0:00.51 httpd
Also, I forgot to mention its 1.5.5 of SVN (1.5.2 had a mod_ bugfix for a memory leak).
What interests me at the moment is diagnosing which module it is (as others running 1.5.5 don't report this issue). It's a fairly vanilla httpd setup other than the svn config.
Adrian
Doesnt look that bad. That 27[789]m reported as SIZE is shared between the processes, shared pages and the like, and the RES isn't excessive in my opinion. What does mod_status and mod_server_info say is going on when you notice the memory starvation?
What precisely did you change with your yum update? Did that change core packages, like libc etc?
Cheers
Tom
--
Alessandro Fantuzzi - O-one s.r.l.
Software developer
-------------------------------------------------------------------
Via
Dante Zanichelli, 61 - 42100 Reggio Emilia
Tel. 0522 930078 - Fax. 0522 387947
-------------------------------------------------------------------
Via
Stendhal, 36 - 20144 Milano
Tel 02.42292057 - Fax 02.47770936
-------------------------------------------------------------------
STRICTLY PERSONAL AND CONFIDENTIAL
This message may contain confidential and proprietary material for the
sole use of the intended recipient. Any review or distribution by
others is strictly prohibited. If you are not the intended recipient
please contact the sender and delete all copies. The contents of this
message that do not relate to the official business of our company
shall be understood as neither given nor endorsed by it.
-------------------------------------------------------------------
