Процессы PHP с жором CPU

Здравствуйте!

Переехали на новый домен, заметили высокую нагрузку процессов php - сначала их 1-2, потом через несколько дней уже было штук 7-10 по 10-15% CPU, иногда пару процессов прыгают до 50-60%. Разумеется, это влияет на отклик сайта, сначала было 1-2 сек, потом стало по 5-8 сек, но техподдержка VDS обновила сервер и подправила конфиг mysql. Тем не менее, процессы php никуда не ушли, и отклик хоть и реже, но все равно прыгает порой до 1,5-3 сек.

Сервер: Быстрый VPS на KVM с Xeon Gold 3x3.0, 4GB DDR4. Конфиг: PHP 7.1 (opcache) + nginx (ssl, http2) + apache + mysql 5.6 (таблицы на InnoDB, но пробовали и на MyISAM), Shop-Script 8 последний. Разумеется, debug-режим отключен. Рестарты mysqld, httpd, nginx ничего не дают.

Ни в логах в бэкенде, ни в серверных логах ничего необычного, разве что роботы заходят, но для такого сервера это копейки. Есть одна особенность с сайтом - на сайте 170 витрин через плагин SEO-регионы, но на предыдущем сайте с таким же кол-во витрин никаких сложностей не было, а посещаемость была даже выше. К сожалению, техподдержка сервера не смогла помочь. Но мы обнаружили следующее: если переименовать папку с сайтом, т.е. перевести его в нерабочее состояние для сервера, то процессы php завершаются и не появляются. Как только возвращаем имя папки обратно, процесс php появляется мгновенно, даже если на сайт никто не заходил. Вроде как даже если отключить приложение Shop, то поведение то же самое, но это проверяли только 1 раз, уже в качестве последнего шага после постепенного отключения практически всех плагинов. Больше не проверяли, так как при отключении и повторном включении приложения Shop движок меняет структуру сайта. Если переименовать не сразу, а через какое-то время, то создаются пустые папки, по памяти вроде wa-config, wa-apps с такими же пустыми подпапками.

Два скрина из top:

1) До обновления сервера на более мощный: https://i.imgur.com/PugHU0d.jpg

2) После обновления: https://i.imgur.com/2zHVNC1.jpg

Разницы практически никакой, синдром тот же.

Скажите, пожалуйста, что это может быть? Что делает движок первым делом после подключения к серверу, без заходов посетителей на него? Сейчас анализируем процессы php через strace, но из ошибок пока ничего криминального - только большое количество команд.

Уже хотим попробовать nginx+php-fpm+memcached и, быть может, mysql 8.0, но вряд ли это устранит проблему появления процессов php, только уменьшит отклик (кстати, насколько в теории?).

4 ответа

  • 1

    Ну так это боты налетели и изучают ваш новый домен.... Нет?  Выше нагрузка на процессор? Ну кеш набивается потихоньку... 170 поддоменов это смело...  Вопрос "нафига" задавать уж не буду, но при таком количестве поддоменов надо быть готовым ко всему =)  И пяток ботов - не так уж и много.

    Сейчас тоже наблюдаю за сайтом который сменил сервер. Поддоменов там порядка 80. Вероятно, увидели смену IP и налетели. Боты стадами пасутся. одновременно по 12-15, в пиковые моменты до 18-20 процессов висит. 

    До этого наблюдал за сайтом который тоже переехал на новый сервер. Сразу после переезда картина такая же была. По прошествии месяца-полутора пришло в норму.

  • 1

    Скажите, а у вас что, бесконечные значения max_requests и request_terminate_timeout у php-fpm пула?

    Что мешает их ограничить до нормальных значений(ну скажем 100-500 и 30-60с)? На крайний случай сделать два пула php для админкии для витрины с разными наборами таймаутов.
    И поверьте, после этого вы забудете про все эти "зависания".
    Для витрины 30с - это даже много. Если у вас на витрине есть операции, которые php обрабатывает дольше, то у вас большие проблемы -)

  • 1

    И поверьте, после этого вы забудете про все эти "зависания"

    Я не говорил о зависаниях в чистом виде.  Под "висит" имелось в виду что единомоментно можно увидеть до 20 работающих и потребляющих более или менее значимые ресурсы процессов. И, собственно, я думаю топикстартер тоже об этом.

    • +1

      Играть в телепатию давно надоело -)
      У топикстартера этот момент не раскрыт. Говорится просто о кол-ве "висящих" процессов. А вот обслуживают они долго один и тот же реквест или это обработка разных запросов непрерывно - вопрос.
      Мой совет был от первого.
      От второго - crawl-delay и всякие технические ухищрения типа limit_req_zone в nginx помогут. В частности, в подобной ситуации на ~1500 поддоменах неплохо помогло разделение crawl-delay на поддоменах в диапазонах от 100 до, например, 500с рандомно(делалось простой генерацией в консоли). Они тогда наваливались не все толпой на все поддомены, а слехка распеределённо.

  • 1
    Worker 9 июня 2020 20:40 #

    "... но при таком количестве поддоменов надо быть готовым ко всему" - кол-во поддоменов для такого сервера и связки apache+nginx небольшое. Как уже было сказано ранее, на предыдущем сайте таких проблем не наблюдалось. Изменился только дизайн, какой-то набор плагинов и всё. Менялся домен, но не менялся IP.

    Всех популярных и зловредных ботов порезали через htaccess и конфиг nginx. Дополнительно режем их по приложению Метрика, там отображаются некоторые гады. Сейчас практически только поисковые роботы активно сканируют сайт, но опять же не настолько жестоко для сервера.

    Что касается Crawl-Delay - это, скорее, панацея. У нас стоит 60 сек, в т.ч. для поддоменов, что более чем, но данная директива в robots необязательна к исполнению ни роботами, ни уж тем более сканирующими ботами - если только владелец бота будет милостив и согласится не насиловать сайт по просьба владельца сайта.

Добавить ответ

Чтобы добавить комментарий, зарегистрируйтесь или войдите