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.

________________________________

Von: Alessandro Fantuzzi [mailto:fantu...@o-one.net] 
Gesendet: Freitag, 3. April 2009 15:46
An: users@httpd.apache.org
Betreff: Re: [us...@httpd] Apache memory hog



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.dom...@iz.bwl.de] 
        Sent: 03 April 2009 14:23
        To: users@httpd.apache.org
        Subject: AW: [us...@httpd] 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...@googlemail.com] 
        Gesendet: Freitag, 3. April 2009 15:16
        An: users@httpd.apache.org
        Cc: a...@ice-sa.com
        Betreff: RE: [us...@httpd] 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
        
        
        ---------------------------------------------------------------------
        The official User-To-User support forum of the Apache HTTP Server 
Project.
        See <URL:http://httpd.apache.org/userslist.html> 
<http://httpd.apache.org/userslist.html>  for more info.
        To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
           "   from the digest: users-digest-unsubscr...@httpd.apache.org
        For additional commands, e-mail: users-h...@httpd.apache.org
        
        
        ---------------------------------------------------------------------
        The official User-To-User support forum of the Apache HTTP Server 
Project.
        See <URL:http://httpd.apache.org/userslist.html> 
<http://httpd.apache.org/userslist.html>  for more info.
        To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
           "   from the digest: users-digest-unsubscr...@httpd.apache.org
        For additional commands, e-mail: users-h...@httpd.apache.org
        
        
        ---------------------------------------------------------------------
        The official User-To-User support forum of the Apache HTTP Server 
Project.
        See <URL:http://httpd.apache.org/userslist.html> 
<http://httpd.apache.org/userslist.html>  for more info.
        To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
           "   from the digest: users-digest-unsubscr...@httpd.apache.org
        For additional commands, e-mail: users-h...@httpd.apache.org
        
        
          



-- 


Alessandro Fantuzzi - O-one s.r.l.
E-mail: fantu...@o-one.net
Software developer

www.o-one.net

-------------------------------------------------------------------
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.
-------------------------------------------------------------------

Reply via email to