 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
22 messages in ru.sysoev.nginxphp-fastcgi and memory leaks| From | Sent On | Attachments |
|---|---|---|
| Phillip B Oldham | Mar 25, 2008 2:43 am | |
| Reinis Rozitis | Mar 25, 2008 4:30 am | |
| Phillip B Oldham | Mar 25, 2008 4:47 am | |
| Yordan Georgiev | Mar 25, 2008 1:01 pm | |
| Phillip B Oldham | Mar 26, 2008 1:12 am | |
| Thomas | Mar 26, 2008 2:43 am | |
| Phillip B Oldham | Mar 26, 2008 3:00 am | |
| Thomas | Mar 26, 2008 3:08 am | |
| Corey Donohoe | Mar 26, 2008 7:18 am | |
| Yordan Georgiev | Mar 26, 2008 7:27 am | |
| Rob Schultz | Mar 26, 2008 12:14 pm | |
| Phillip B Oldham | Mar 28, 2008 2:36 am | |
| Thomas | Mar 29, 2008 1:41 pm | |
| Reinis Rozitis | Mar 30, 2008 5:56 pm | |
| Thomas | Mar 31, 2008 4:41 am | |
| Phillip B Oldham | Mar 31, 2008 4:54 am | |
| Grzegorz Nosek | Mar 31, 2008 5:06 am | |
| Phillip B Oldham | Mar 31, 2008 5:27 am | |
| Grzegorz Nosek | Mar 31, 2008 5:40 am | |
| Phillip B Oldham | Mar 31, 2008 5:46 am | |
| Grzegorz Nosek | Mar 31, 2008 6:33 am | |
| Phillip B Oldham | Mar 31, 2008 6:44 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | php-fastcgi and memory leaks | Actions... |
|---|---|---|
| From: | Phillip B Oldham (phil...@public.gmane.org) | |
| Date: | Mar 25, 2008 2:43:51 am | |
| List: | ru.sysoev.nginx | |
Further to the email below, I'm still having problems with PHP5 fastcgi and nginx. I'm finding that php slowly takes up 100% of the available memory and starts to drop connections at around 70%. At the moment I've got monit restarting the fastcgi processes when the memory usage hits 70%, but this isn't optimal as the scripts I'm running shouldn't take anywhere near that on a virtual server with 300MB dedicated ram.
I'm wondering whether anyone else has come across the same problem running php5 fastcgi who has managed to find a fix or work-around?
I was seeing something similar with PHP5 fastcgi and lighttpd, though it was a lot more than 10% - maybe 25-50. I'm getting a little worried as I think I may be seeing the same thing at around 5-10% with nginx.
During my investigations into why this was happening in lighttpd, I came across the following paragraph in the mod_fcgi docs:
Adds a MaxRequestsPerProcess parameter that allows mod_fcgid to exit after handling a certain number of requests, similar to the existing ProcessLifeTime option.
This solves a problem with PHP in FastCGI mode. By default, PHP stops accepting new FastCGI connections after handling 500 requests; unfortunately, there is a potential race condition during the PHP cleanup code in which PHP can be shutting down but still have the socket open, so mod_fcgid under heavy load can send request number 501 to PHP and have it "accepted", but then PHP appears to simply exit, causing errors.
Not too sure if your rails app/mongrel is restarting processes after a set limit and coming across the same race condition?
If this problem is could become aparent in nginx it would be great if there was a plugin to spawn and manage fcgi threads which could limit the number of connections to each backend.
HTH. Phill
begin:vcard fn:Phillip Oldham n:Oldham;Phillip org:The Activity People;Systems Development email;internet:phill-ABPfyfql6ydQOjYTieCOMbyq0pUa53/3...@public.gmane.org title:Chief Programmer tel;work:0870 162 4847 x-mozilla-html:TRUE url:http://theactivitypeople.co.uk/ version:2.1 end:vcard