Делюсь с вами историей из практики, которая случилась на днях. Она вышла типовой и показательной, поэтому рассказываю. Поясню, что я участвовал в рамках платной консультации и настройками не занимался. Только предлагал разные варианты на основе своего опыта. Ко мне обратился владелец сервиса со средней нагрузкой примерно в 600 rps (запросов в секунду). Использовался типовой стек на базе Nginx, Php-fpm, MySQL и некоторых вспомогательных сервисов. Все запросы клиентов стекались в один php скрипт. Частично был настроен мониторинг на базе Prometheus и Grafana, но сделан был для галочки и большая часть нужных метрик там отсутствовала (по nginx и php-fpm ничего не было). MySQL сервер был отдельной VPS, запросы к нему шли через ProxySQL. Проблема была на первый взгляд простая. Часть клиентов получали 502 ошибку, которая в nginx выглядела вот так: connect() to unix:/run/php-fpm/www.sock failed (11: Resource temporarily unavailable) while connecting to upstream Обычно это следствие нехватки php-fpm воркеров. Если ресурсы сервера позволяют, то надо увеличить их количество. Ресурсов было много. Из 16 ядер и 32 Гб памяти занято было от силы 3-4 ядра и 3-4 Гб памяти. При этом в php-fpm был настроен статичный запуск воркеров, а их кол-во всего 32, что по моим представлениям очень мало для подобной задачи и сервера. Дальше началось самое интересное. Увеличение числа воркеров не приводило к исчезновению ошибки об их нехватке в nginx. Более того, чем больше добавляешь воркеров, тем больше 502 ошибок у пользователей и тем меньше 200 ответов. После того, как поиграли с числом воркеров php-fpm, я понял, что узкое место не со стороны веб сервера, но так как мониторинга не было, не понятно, куда смотреть. На всякий случай проверили лимиты операционной системы на подключения к unix сокетам, сетевым подключениям, файловым дескрипторам. Проблем не было. Потом таймауты nginx и fastcgi. На первый взгляд тоже всё в порядке. Настроили быстро мониторинг php-fpm и через консоль вручную смотрели метрики, но ничего полезного там не увидели. Для эксперимента я предложил сменить режим работы php-fpm с unix сокета на tcp и добавить много воркеров, штук 100-200, можно было бы и 500, сервер тянул. Ошибка в Nginx изменилась, но суть осталась прежней. Там просто по таймауту отваливались подключения к воркерам. Увеличение количества воркеров не решало проблему. На этом этапе я уже окончательно убедился, что проблема не с веб сервером. У меня были две идеи: либо не тянет БД, либо в php скрипте какой-то замкнутый цикл, который с ростом числа воркеров просто плодит паразитную нагрузку, а запросы клиентов так и остаются с ошибками. Для БД был какой-то мониторинг, но он толком ничего не показывал. Были метрики числа и времени выполнения запросов, число столбцов, участвовавших в них и что-то ещё. Эти метрики показывали ровные линии, без всплесков и провалов. Каких-то базовых метрик на тему производительности не было, поэтому трудно было оценить, что там вообще происходит. По htop повышенная нагрузка не просматривалась. В завершении я предположил, что в ProxySQL стоит ограничение на входящие запросы, поэтому сверх лимита они все отбрасываются, либо висят в очереди, поэтому нагрузка на MySQL ровная. На всякий случай ещё проверил количество TCP подключений к серверу, нет ли там узкого места. Его не было, коннектов не сказать, что сильно много и ни в какие лимиты они не упирались. На этом распрощались. Потом заказчик добавил ещё один веб сервер и часть запросов отправил туда, но это не помогло. Проблема решилась просто — увеличили в 2 раза ресурсы MySQL сервера и всё поехало, как надо. 💡Написал я всё это к чему. Всегда надо делать хороший мониторинг. Без него решать подобные задачи трудно, уходит много времени, результат непредсказуем. Настройка мониторинга заняла бы меньше времени, чем в итоге решение всего лишь одной проблемы. Весь софт, который участвует в работе системы, должен мониториться, и не для галочки, а нужными метриками. #мониторинг