Зависает /wp-cron.php?doing_wp_cron

Редактор одного из сайтов стал жаловаться на частые обвалы сайта во время интенсивной работы в админке WordPress. В лучшем случае админка тормозила, иногда падала. Смотрю top вижу кучу не завершенных апачей. Странно. WordPress кешированный SuperCache, настройки апача проверенные временем, нападения ботов не заметно. Открываю server-status , дабы посмотреть какие страницы может тормозят. И вижу сразу 4 штуки процесса

POST /wp-cron.php?doing_wp_cron

Я всегда думал что вордпрессовский wp-cron.php отвечает только за отложенную публикацию. Оказалось что на этого планировщика понавешано много чего. Чтобы разобраться что сейчас делает wp-cron нужно установить плагин WP-Crontrol. В репозитории описано, что с версией WordPress 3.xx он не совместим, но у меня нормально работает.

Так вот запускаем плагин и видимо, что на wp-cron висит несколько запланированных задач, но ведь POST /wp-cron.php?doing_wp_cron в server-status висит сейчас … Не понятно. Случайно обновил Crontrol в момент после публикации редактором нового поста и увидел два новых процесса со статусом ( now ) это были sm_build_cron и ping_cron. Первый оказалось собирает карту сайта в плагине XML Sitemap в фоне при публикации новой статьи, а второй пингует. И все эти процессы пускаются как раз через wp-cron.php .
Пока отключил сборку карты и пинги из XML Sitemap. Вроде полдня работает нормально. Будем посмотреть что дальше.

17 декабря 2010 |

6 Комментариев к “Зависает /wp-cron.php?doing_wp_cron”

  1. Тим 25 декабря, 2010

    Приветствую. У меня аналогичная проблема, грешу на Yet Another Related Posts Plugin хотя возможно это действительно Google XML Sitemaps. Нагрузка скачет с периодом в 2 часа.

  2. Azzrael 26 декабря, 2010

    У меня после отглючения создания сжатой версии карты и отключения пингования из XML Sitemap – wp-cron.php?doing_wp_cron больше не виснет. Но походу это только часть проблемы. На нормально отсроенном серваке врядли XML Sitemap вызвал бы подвисоны, мне кажется. Сейчас вот разбираюсь потихоньку.

  3. Reginald 29 декабря, 2010

    Аналогичная проблема)

    Такое ощущение что сломали что то в WP, потому что процессы не завершаются вообще и сервер на юбунте вешается на попытках завершения этих процессов.

    Аналогично настроенный сервер работает с двумя Битркисами и нагрузки у него меньше и зависаний таких нет.

    Так что вот… Если разберусь в чем косяк – могу написать.)

  4. Azzrael 29 декабря, 2010

    я натянул копию проекта на фряху в вмваре. косяков до сих пор не вижу. всю голову уже сломал. если раберешься ага напиши плз.

    вообще всё что дергал всё бестолку. наиболее ощутимо влияет на зависоны только то что к базе обращается. Если ориентироваться на значение Request Per Second в ab то оно возврастает вдвое если отключить плагины интенсивно дергающие MySQL ( у меня это Postratings, Simpletags ). Так же вдвое вырастает если угадать с кешированием MySQL. Включение eAccelerator улучшает ситуацию процентов на 30…

  5. Reginald 7 января, 2011

    В ВП в файле wp-cron.php я закомментировал строку
    ignore_user_abort(true);
    Эта функция даже при превышении временного лимита установленного для php скриптов продолжала выполнение скрипта – в результате один из процессов апача находил что скрипт выполняется долго и пытался его завершить – в результате система вешалась. После закомменчивания той строки ситуация разрешилась.

  6. Azzrael 7 января, 2011

    хм.. спасибо за подсказку. вопрос что так капитально подвешивает крон.
    к примеру если теже пингаторы, то убрав ignore_user_abort(true) крон завершится сразу после
    max_execution_time несмотря на успешность пинга ( как я понимаю ). А это не подходящий вариант.
    но в любом случае вариант.