Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running Drupal 6 with Nginx 1.5.1 and PHP-FPM (PHP 5.3.26) on a 1GB single core VPS with 3GB of swap space on SSD storage. I just switched from shared hosting to this unmanaged VPS because my site was getting too heavy, so I'm still learning the ropes. I have moderately high traffic, I don't really monitor it closely but Google Adsense usually record close to 30K page views/day. I usually have 50 to 80 authenticated users logged in and a few hundred more anonymous users hitting the Boost static HTML cache at any given moment.

The problem I'm having is that PHP-FPM frequently stops responding, resulting in Nginx 502 or 504 errors. I swear I have read every page on the internet about this issue, which seems fairly common, and I've tried endless combinations of configurations, and I can't find a good solution. After restarting Nginx and PHP-FPM, the site runs really fast for a while, and then without warning it simply stops responding. I get a white screen while the browser waits on the server, and after about 30 seconds to a minute it throws an Nginx 502 or 504 error. Sometimes it runs well for 2 minutes, sometimes 5 minutes, sometimes 5 hours, but it always ends up hanging. When I find the server in this state, there is still plenty of free memory (>500MB or more) and no major CPU usage, the control and worker PHP-FPM processes are still present, and the server is still pingable and usable via SSH. A reload of PHP-FPM via the init script revives it again. The hangups don't seem to correspond to the amount of traffic, because I observed this behavior consistently when I was testing this configuration on a development VPS with no traffic at all.

I've been constantly tweaking the settings, but I can't definitively eliminate the problem. I set Nginx workers to just 1. In the PHP-FPM config I have tried all three of the process managers. "Dynamic" is definitely the least reliable, consistently hanging up after only a few minutes. "Static" also has been unreliable and unpredictable. The least buggy has been "ondemand", but even that is failing me, sometimes after as much as 12 to 24 hours. But I can't leave the server unattended because PHP-FPM dies and never comes back on its own. I tried adjusting the pm.max_children value from as low as 3 to as high as 50, doesn't make a lot of difference, but I currently have it at 10. Same thing for the spare servers values. I also have set pm.max_requests anywhere from 30 to unlimited, and it doesn't seem to make a difference.

I've also been using APC and Redis caching to take some of the load off the the database, but the PHP-FPM problem exists both with and without these mechanisms activated.

According to the logs, the PHP-FPM processes are not exiting with SIGSEGV or SIGBUS, but rather with SIGTERM. I get a lot of lines like:

WARNING: [pool www] child 3739, script '/var/www/drupal6/index.php' (request: "GET /index.php") execution timed out (38.739494 sec), terminating

and:

WARNING: [pool www] child 3738 exited on signal 15 (SIGTERM) after 50.004380 seconds from start

I actually found several articles that recommend doing a graceful reload of PHP-FPM via cron every few minutes or hours to circumvent this issue. So that's what I did, "/etc/init.d/php-fpm reload" every 5 minutes. So far, it's keeping the lights on. But it feels like a dreadful hack. Is PHP-FPM really that unreliable? Is there anything else I can do? Thanks a lot!

share|improve this question

migrated from webmasters.stackexchange.com Jun 28 '13 at 18:50

This question came from our site for pro webmasters.

    
What's your fpm request_terminate_timeout set to? –  3molo Jun 28 '13 at 19:03
    
Do yourself a favor, move to Drupal 7 as fast as you can. –  Michael Hampton Jun 28 '13 at 19:03
    
@3molo: request_terminate_timeout = 30s –  user12361 Jun 28 '13 at 19:08
    
@ Michael: I'm running the cache_backport module, which shoehorns in the significantly better cache backend from Drupal 7. –  user12361 Jun 28 '13 at 19:10
    
Are you really 100% sure that the problem will not disappear when APC is deactivated? This really sounds like an APC related problem. –  shakalandy Jun 28 '13 at 20:19
show 5 more comments

2 Answers

up vote 2 down vote accepted

Have you tried another Optimizer or did you try using apc.filter? This really sounds like an APC related issue because the stability of APC always depends on the used code and and apc configuration.

share|improve this answer
    
I have no idea which script might be causing the incompatibility with APC, so I'd prefer to avoid the apc.filters route. But disabling APC entirely and replacing it with Zend Optimizer+ is working beautifully. Xcache also seems to work well. APC was definitely the problem. Accepting this answer. Thanks a lot! –  user12361 Jul 6 '13 at 1:40
add comment

Came here by Googling, sharing some experience.

Had the same problem, but in Drupal 7! (sorry @michael Hampton ;-) Drupal 6 is running fine on the same VPS (2048 MB, 2× 2.4Ghz@60%, NGINX, APC). Drupal 7 get stucked after ~4 hours, like a traffic jam or something ;-) For 2 weeks i'm trying and searching different options.

It seems that finally disabling APC did the trick. Before (APC on), CRON in Drupal gave an error in the slowlog. Without APC, the site seems a little bit faster.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.