У меня есть сервер, на котором запущено несколько блогов WordPress, и в некоторых из них есть несколько сотен / тысяч сообщений.
Каждые пару дней сервер замедляется до сканирования из-за того, что в Wordpress запущен файл с именем WP-cron.php. Весь мой журнал процессов apache превращается в это:
http: // imgur.com/A7K9k.png
Раз, что совсем немного. И сервер не идет.
Каждый процесс занимает около 1,1% оперативной памяти. И когда у нас будет 50 из них на ходу. Это безумие. Не все из одного блога, они довольно широко распространены. На странице процессов Apache в WHM они ВСЕМ обычно имеют статус «C», что означает закрытие. Но они могут сидеть там до тех пор, пока сервер не выйдет из строя, и они все еще сохраняют память.
Просто погуглите "wp-cron.php load", и вы найдете множество людей с похожими проблемами.
В любом случае, мы думаем, что это связано с тем, что пользователи добавляют тонну мертвых «пинглистов» в свою установку WordPress. Что, в свою очередь, проходит через них бесконечно.
Проблема №1. Есть ли у кого-нибудь другие предложения о том, что может вызвать бесконечный цикл файла Wordpress wp-cron.php. Я все еще думаю, что дело в пингах, потому что у всех людей, с которыми мы связались по поводу заоблачной нагрузки на их учетные записи, были огромные списки запросов.
Проблема №2. Даже если дело в чрезмерном количестве пинглистов в wordpress. Мы не можем следить за каждой учетной записью на сервере, ожидая, пока она начнет порождать процессы wp-cron. Часто это происходит в одночасье, и в 2 часа ночи я начинаю получать SMS-оповещения о загрузке.
У меня установлен CSF, который, по-видимому, завершил бы процессы, если бы они выполнялись более XXX раз. Но мне сказали, что он не будет ловить процессы, потому что они попадают в состояние «закрытия» (они отображаются как «C» на странице Apache WHM). Очевидно, CSF будет убивать только те процессы, которые «запущены», которые C не считает.
Я видел другие сценарии, например: http://dltj.org/article/die-apache-die/ . Я посмотрел на статистику / proc. Но я был поражен тем, в какой из разделенных частей идет время. И если бы я мог каким-то образом подключить его обратно к реальному процессу Apache, чтобы я мог видеть, какой файл был запущен (так что только закрывайте соединения, подключенные к wp-cron.php, с состоянием «C»).
В целом я знаю, что проблема 2 затушевывает настоящую причину. Но я все же положил все это на чрезмерные списки пинг-листов в Wordpress. Но я просто не могу сидеть и присматривать за каждой установкой 24/7. Поэтому мне нужен способ сохранить сервер, когда я недоступен.
Любая помощь приветствуется.
Может ли у вас другой сервер запускать тот же сайт и запускать там cron? Это то, что мы сделали для некоторых из наших более крупных сайтов: мы отключили wp-cron на веб-сайтах клиентов, но у них есть внутренний, работающий ..
Добавить определение ('DISABLE_WP_CRON', true); в wp-config,
Взгляните на отличный наблюдатель / убийца процессов, psmon. Это просто сценарий Perl, который демонизирует себя в фоновом режиме и содержит файл конфигурации в стиле Apache с возможностью уничтожения процессов, если они потребляют X объема памяти или если они были израсходованы X количества процессорного времени. PSMon может предупредить вас через системный журнал или по электронной почте, когда решит остановить процесс.
Кроме того, вы можете обернуть wp-cron.php вокруг сценария оболочки, который будет использовать файл блокировки и следить за тем, чтобы в любой момент времени работала только одна копия wp-cron.php.
Вопрос в том, будут ли ваши пользователи удобны, не имея wp-cron.php .. зависят ли от них ваши блоги / плагины. Если нет, вы можете использовать mod_security или просто конфигурацию apache для блога wp-cron.php от выполнения. Для каждого блога WP будет запускать собственный экземпляр wp-config.php.