Поиск проблем на сервере (загрузка CPU 100%). Разбор.

Автор: Роман Чернышов Опубликовано: 15 апреля 2023

Доброго времени друзья! В этой небольшой статья я расскажу о недавно проведенном анализе сервера на предмет поиска и последующего устранения проблем, которые негативно сказываются на его производительности, а именно периодически приводили к загрузке процессора по всем ядрам на 100%. Забегая вперед, сразу оговорюсь, что проблема была в работе службы сервера баз данных MySQL, но как оказалось не все так очевидно(почему и потребовался летальный анализ работы всех служб), а сами проблемы крылись далеко за пределами MySQL, но все-же влияли на его работу, что и приводило к такому печальному итогу. Далее обо всем по порядку.

Проблема

Периодически возникает нагрузка на CPU до 100% по всем ядрам, основной потребитель ресурсов служба MySQLd. Всплеск трафика укладывается в допустимые нормы, и к DDOS не относится.

Параметры сервера и сайта

ПроцессорIntel Xeon W-2255 3.7 ГГц, 10 ядер
Память 64 ГБ DDR4
SSD NVME 400 Gb x 2
Операционная система CentOS 7, Nginx + PHP-FPM + Apache + MySQL
Защита от DDoS-атак на уровне внешнего проксирующего сервера
PHP фреймворк Yii
Трафик ~30 000 хостов, в сутки

Результат изучения и рекомендации

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

1. На сайте используется версия PHP 5.4, эта версия устарела и перестала поддерживаться аж в 2015 году. В ряде её слабых мест в том числе расширения(mysql, mysqli, pdo) для работы с MySQL, которые могут работать медленно, а также слабая реализация ООП. В целом PHP 5.4 сам по себе медленный.

Рекомендация: Обновиться хотя-бы до версии PHP 5.6 (там существенно улучшена поддержка ООП), лучше 7.3 или 8.

2. На сайте, для частичной реализации функционала, используется PHP фреймворк Yii (похоже еще версии 1), который изначально спроектирован доя работы в парадигме ООП. Возможно ядро у него старое(из-за сильных переделок, сложно понять точную версию), и под PHP 5.4 он работает нормально, но тем не менее этот момент добавляет важности пункту 1.

3. База данных содержит почти четыре сотни таблиц, из них несколько десятков таблиц не имеют настроенных индексов, или имеют частично настроенные индексы! Это значит, что операции выборки данных из этих таблиц(даже при условии если там мало строк), могут приводить к очень большой нагрузке на БД. Этот момент критичен. Один из примеров, таблица tv_anons имеет почти 900 тысяч строк и только один индекс по ID, при этом в таблице есть поля использующиеся для выборки данных, такие как type_id, genre_id, category_id — и по ним индексы не настроены! Более того, у данных полей задан строковой тип varchar(45), вместо числового int. Одна лишь эта таблица, может положить весь сервер — создав нагрузку на MySQL и жесткий диск.

Рекомендация: Крайне рекомендую настроить индексы для всех таблиц.

4. Связка Nginx и PHP5.4-FPM имеет ограничения в конфигурации, которые ежедневно приводят к обвалу веб-сервера, по причине того, что веб-сервер не может обслужить несколько запросов одновременно. В логе ошибок, очень много строк(каждый день) с предупреждением о достижении лимита количества подключений. Ошибка server reached pm.max_children.

В логах множество записей о падении веб-сервера, даже без нагрузки (exited, sratred).

Рекомендация: Корректно настроить PHP-FPM.

5. На сервере 64 Gb памяти, плюс 32 Gb swap системы(на диске NVME). Но используется только 7 Gb памяти, а swap вообще не задействован. Т.е., вместо того, чтобы перераспределить нагрузку между жестким диском и ОЗУ, поместив в ОЗУ значительную часть часто используемых данных из БД, система подгружает данные с диска из файлового хранилища БД. То есть БД(сервер баз данных) сконфигурирована без учета возможности использовать ОЗУ для хранения большого кеша. Память ОЗУ просто не используется.

Рекомендация: Настроить MySQL с учетом большого объема ОЗУ. По возможности внедрить в Yii поддержку Memcached (кеширование на уровне PHP). Это существенно ускорит работу с БД и снизит нагрузку.

6. На сервере установлен Solr — служба полнотекстового поиска в PHP. Которая пишет в логи очень много данных(десятки строк в секунду), запросов, желательно настроить службы так, чтобы снизить нагрузку по части логирования(на жесткий диск). В пиковых нагрузках, это может усиливать общий эффект нагруженности системы (хоть на сервере и стоит NVME). Плюс иногда возникающие проблемы в подключении к MySQL со стороны Solr (возможно проблема в связке с п.8).

Рекомендация: Настроить корректно логирование Solr.

7. nGinx также в конфигах содержит ошибки, которые при падении PHP-FPM и перезагрузке nGinx, дают о себе знать(conflicting server name, ignored). На производительность это не влияет, но может замедлять перезапуск nGinx при падениях.

Рекомендация: Настроить корректно nGinx

8. Проблемы в MySQL. Частое падение БД — Процесс убивается системой. Вероятно проблема в конфигурировании БД. Но, точную причину не установил, может пункт 9(может в комплексе).

Рекомендация: Настроить корректно MySQL (MariaDB).

9. Проблема в настройка ОС CentOS на предмет максимально разрешенного открытия числа файлов, в логах ошибки вида: «Could not increase number of max_open_files to more than 32768 (request: 482095)». Проблема критичная. Также влияющая на работу БД и всех служб сервера.

Рекомендация: Настроить корректно директивы ОС CentOS 7.

10. Ошибки на уровня ядра, с вероятным падением PHP FPM: kernel: php-fpm[5981]: segfault at 1000705 ip 0000562c5d5b994a sp 00007ffec5276440 error 4 in php-fpm[562c5d344000+3d0000]. Возникает каждые 15-20 минут. Возможности причина в пункт 4 (или в совокупности). Не критично. Но в нормально работающей системе такого быть не должно, на производительность не влияет.

Рекомендация: Разобраться и устранить.

11. Иногда возникают проблемы в движке Java (Error parsing HTTP request header). На производительность не влияет, но желательно разобраться, на производительность не влияет.

Рекомендация: Разобраться и устранить.

12. На сервере установлен Redis. Есть проблемы с настройками прав доступа(Failed opening the RDB file crontab (in server root dir /etc) for saving: Permission denied), из-за чего задания вызываемые по Cron не могут быть выполнены, иногда происходит падение службы (redis.service stop-sigterm timed out. Killing.), на производительность не влияет.

Рекомендация: Разобраться и устранить.

13. Иногда возникают проблемы у Apache . Не может дождаться завершения выполнения скрипта и уход в перезагрузку (caught SIGWINCH, shutting down gracefully), на производительность не влияет.

Рекомендация: Разобраться и устранить.

Заключение

После выполнения всех рекомендаций, скорость работы сайта и сервера заметно возросли, все возникающие ошибки были устранены и больше не возникали. Нагрузка на CPU снизилась и более скачков нагрузки до 100% по всем ядрам не наблюдалось. Основными улучшениями можно назвать пункты 1, 3, 4, 5 — именно они существенно повлияли на производительность всей системы.

Друзья, если вам нужна помощь в анализе работы сервера, в поиске проблем с последующим решением их, пожалуйста обращайтесь, буду рад сотрудничеству!

Заказать анализ сервера