1

I'm running a dedicated server with nginx, PHP-FPM, MySQL and have a few sites running on it but I'm having a timeout issue everyday, pretty much every 24 hours from the site that is running WordPress.

PHP-FPM error:

[14-Jan-2012 04:00:48] WARNING: [pool www] child 2759, script '/home/fez/www/index.php' (request: "GET /index.php") execution timed out (73.614398 sec), terminating
[14-Jan-2012 04:00:48] WARNING: [pool www] child 2759 exited on signal 15 (SIGTERM) after 114278.396462 seconds from start

nginx error:

2012/01/14 04:00:48 [error] 1629#0: *859825 upstream timed out (110: Connection timed out) while reading upstream, client: 82.130.40.76, server: www.flesheatingzipper.com, request: "GET /gaming/2011/11/skyrim-guide-dragon-shout-rune-locations-youre-welcome/ HTTP/1.1", upstream: "fastcgi://unix:/tmp/php5-fpm.sock:", host: "www.flesheatingzipper.com"

WordPress crons:

  • jetpack_clean_nonces - Hourly
  • akismet_scheduled_delete - Daily @ 3:00am
  • wp_version_check - Twice daily (10am/10pm)
  • wp_update_plugins - Twice daily (10am/10pm)
  • wp_update_themes - Twice daily (10am/10pm)
  • wp_scheduled_delete - Daily @ 10am

Here is my PHP-FPM config: http://pastebin.com/ppsWeHVN

Improve this question
11
  • Is it always at 4am everyday or does it happen randomly throughout the day?
    – Travis Campbell
    Jan 16, 2012 at 20:40
  • Have a look through your cron jobs (/etc/crontab, /etc/cron.daily etc) . Is there anything running around the time that this is happening? Pay special attention to logrotate jobs. What operating system / distro are you using?
    – Tom Hudson
    Jan 16, 2012 at 21:17
  • @TravisCampbell It started at 4 and has creeped up to 5am this moring. It throws time outs for a few minutes then back to normal.
    – kel
    Jan 16, 2012 at 23:48
  • @TomHudson Nothing special running, nothing running on the exact times logrotate runs at 3:11am everyday. I'm running CentOS 6.2 (64bit), nginx 1.0.11, PHP-FPM (latest). I don't know when WordPress is running it's crons though.
    – kel
    Jan 17, 2012 at 0:04
  • Think we need some more info. Change in php.ini to include a stacktrace with the error-message.
    – Gustav
    Jan 17, 2012 at 12:41

4 Answers 4

Reset to default
3

You never gave your nginx configuration. However, SIGTERM (15) on PHP-FPM children can be one of these:

  • Open file descriptors too low (edit /etc/security/limits.conf and create an entry for your web user and set 'nofiles' to something higher). Also set rlimit_files to something higher in your PHP-FPM config if you use that

  • You are using fastcgi_keep_conn on in your nginx config. This has disastrous results with php-fpm with 'ondemand' and 'dynamic' configurations as php-fpm tears down and builds up new php-fpm children, but nginx doesn't know how to reconnect, so your site will fall over.

Improve this answer
1

WordPress does odd things with cron jobs. It has a wp-cron.php file that gets included/executed on page requests. This is used to simulate a crontab for people who don't have access to a real crontab.

I suspect you have configured a daily cron job in your WordPress admin centre that does something that takes more than 73 seconds. The first page request 24 hours after the last time it ran will trigger that cron job again and cause another timeout.

As for why it eventually succeeds, I can only guess that it is either getting part of the job done during each run and saving its progress or that the OS is caching more and more of the files that it is touching until it can get the whole cron job done faster than the timeout.

Some people have worked on making WordPress cron jobs work via a normal crontab.

The akismet_scheduled_delete - Daily @ 3:00am cron job looks like the most likely culprit. Either there's a difference between the server's and PHP's views of the current timezone meaning that the 3am job actually runs at 4am or the job takes over an hour to execute.

Improve this answer
1

It looks like it was related to the Wassup plugin. I enable PHP slow logs and receive the below error after the site crashed again but during the day. After I disabled the plugin the site was instantly faster and have not had and slow downs or crashed like before.

[25-Jan-2012 15:09:20]  [pool www] pid 3593
script_filename = /home/fez/www/index.php
[0x00007f353cb75890] mysql_query() /home/fez/www/wp-includes/wp-db.php:1091
[0x00007f353cb75670] query() /home/fez/www/wp-includes/wp-db.php:1375
[0x00007f353cb753d8] get_results() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:553
[0x00007f353cb75278] getMySQLsetting() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:180
[0x00007f353cb750c0] defaultSettings() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:232
[0x00007f353cb74fc0] getSettings() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:212
[0x00007f353cb74ef8] loadSettings() /home/fez/www/wp-content/plugins/wassup/lib/wassup.class.php:90
[0x00007f353cb74b10] wassupoptions() /home/fez/www/wp-content/plugins/wassup/wassup.php:1822
[0x00007f353cb749d0] wassupPrepend() /home/fez/www/wp-content/plugins/wassup/wassup.php:326
[0x00007fff788d6280] wassup_init() unknown:0
[0x00007f353cb747a8] call_user_func_array() /home/fez/www/wp-includes/plugin.php:405
[0x00007f353cb74410] do_action() /home/fez/www/wp-settings.php:304
[0x00007f353cb74320] +++ dump failed
Improve this answer
0

i am guessing you have a database dump or backup running and some tables are getting locked in the process of it, that always makes for some nice timeouts. Try enabling mysql slow queries log and check for slow queries around 4am.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .