Hi list, We are experiencing a memory leak on our SquirrelMail server since the 5.3 update. The server is fully updated, only stock rpms. The httpd processes are eating all the memory and after swapping like hell, the server became unresponsive and we must hard- reboot it. The server is not that much loaded (max 10-15 concurrent users but with tons of mail in their inbox). Configuration's speaking, nothing was changed before and after the update. Is there someone else experiencing the same thing ? How can I search deeper the origin of the leak ? Thx, kfx
Hi,
We are experiencing the same issue, however using Apache and Tomcat via Proxy AJP to server a Shibboleth IdP on CentOS 5.3 - stock RPMs.
httpd-2.2.3-22.el5.centos tomcat5-5.5.23-0jpp.7.el5_2.1
Since upgrading to 5.3 we have noticed that overnight all 4GB of physical RAM and all 4GB of swap is eaten and the web service unresponsive. We can still SSH into the machine and restart Apache. This rectifies the issue. These are production boxes and subject to numerous connections, we are trying to isolate the trigger. However, the exact same configuration and applications being served under 5.2 exhibit no issue.
I suspect it may be related to this bug, logged with the upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=497077
Cheers,
J.
James Wilson wrote:
Since upgrading to 5.3 we have noticed that overnight all 4GB of physical RAM and all 4GB of swap is eaten and the web service unresponsive. We can still SSH into the machine and restart Apache. This rectifies the issue. These are production boxes and subject to numerous connections, we are trying to isolate the trigger. However, the exact same configuration and applications being served under 5.2 exhibit no issue.
I suspect it may be related to this bug, logged with the upstream:
I was experiencing similar problems with an x86_64 server after upgrading to 5.3. While MySQL, Apache and PHP are installed SquirrelMail was not, nor mail services beyond daily logwatch emails.
Since Apache was serving internal-only sites needed by only a few people in my department, I found that de-tuning the prefork section httpd.conf was an acceptable workaround.
None of the other servers I have upgraded to 5.3 have exhibited this issue, but they are all i386 web servers only and do not mysql installed. Although they do handle 2-3 orders of magnitude more requests than the x86_64 server does.
Thanks, Rick