Из-за чего скачки времени обработки запросов?

Всем привет! Что есть:
  1. сервер: 2 x 2.8 ГГц, оперативка 4 гб, NVMe 50 ГБ (заполнено 13 гб), 200 мбит/с
  2. ubuntu, nginx, php-fpm, php 7.3, laravel, mysql
  3. на нём сервер API, который должен выдавать json строку Яндексу за 3 секунды (API Яндекс.Диалогов), если Яндекс не получает ответа, он закрывает соединение засчитывает ошибку.
  4. Запросов может быть много, особенно вечером


Проблема: от 0.5 % до 1 % запросов выполняются больше 3 секунд, из-за чего образуется ошибка, причём скачки резкие, рандомные, но постоянные. Все остальные запросы выполняются за 0.3 секунд.

Что делал:
- Увеличил оперативку до 6 гб и 3 ядер (вообще не помогло).
- Проставил все индексы в базе данных. (Вообще не помогло).
- Оптимизировал запросы в базу данных с 10-16 до 2-6 за 1 запрос к API (не помогло).
- Поменял Apache на NGINX и php-fpm (не помогло)
- Отключал все сайты кроме проблемного (не помогло)
- Логгирование медленных запросов в БД - пусто.
- Логгирование медленных скриптов в php-fpm - пусто.
- Пытался мониторить через innotop, atop и iotop (везде смешные цифры в десятые проценто, иногда только бд вылезает в топ, но там что то около 5% бывает). И не особо понятно, как мониторить, если я не знаю когда в следующий раз будет скачок.
Куда ещё копать и что делать? Уже неделю сижу и не знаю что ещё попробовать :( Помогите, пожалуйста. Вот скрины от Яндекса:
За сегодня (желтые бугорки) в зависимости от кол-ва нормальных запросов:
5f99ab53474e4728507264.png
Скорость запросов за сегодня:
5f99ac01e97b3622187556.png
Процентное соотношение долгих запросов за весь месяц в процентах:
5f99ac7a4593a555497095.png
Ночью (желтые бугорки) в зависимости от кол-ва нормальных запросов (ночь, единичные запросы):
5f99acdc617ea131849753.png
Причём на последней картинке долгие запросы появлялись, когда были единичные запросы, а когда начались постоянные (большая зелёная гора) - они исчезли.

UPD:
Сделал логирование nginx с временем запросов и обнаружил один такой медленный запрос, почему то у его размер всего 0 байт:
5f9a91008224f930448616.png
  • Вопрос задан
  • 608 просмотров
Пригласить эксперта
Ответы на вопрос 3
1. iotop -okaво время таких фризов
2. переведите режим работы процессоров с энерджи сейв в перфоманс cat /proc/cpuinfo | grep MHz все процессоры должны иметь или максимальную частоту или близкую к ней.
Когда процессор "холодный" то ему нужно время поднять частоту, и получается что он быстрей иногда отрабатывает под нагрузкой чем полностью пустой но с 800MHz
3. не забывайте что php+sql один и тот же запрос могут выполнить с разной скоростью, притом эта разница нифига не в 1% а порой доходит до 300% и усугубляется очередью как в sql так и на любом этапе.
4. Могу вам сказать что по факут является самым распространенным

а) i-o диска особенно HDD ( nvme) можно даже не тестировать.
б) sql параллелит свои запросы но один запрос делает на 1 ядре, в результате 128 ядерный камень по 2Ghz может работать медленней вашего офисного Corei3 поскольку такт на ядро у него больше.
в) кеш php кешируйте все что только можно и грамотно, как правило в этом месте можно ускориться раз в 10-30, даже не оптимизируя запросы в бд
г) находите самые тяжелые запросы в бд и оптимизируйте их.

Теперь что скорее всего происходит
у вас встает очередь запросов в бд, например идет тяжелый хит скажем каталог с 5 фильтрами, в это время остальные запросы встают в очередь, и даже мелкие из них выполняюются медленно поскольку пред ними стоит тяжелый товарищь.
ТАк вот к примеру когда делается 1 тяжелый запрос встало еще 300, и они вместе начинают лезть и выполняться.
В результате получается то - же самое что выделить 10000 файлов в винде на hdd и скопировать параллельно а не последовательно
I-O проседает многократно порой до десятков тыс раз.
Пример утрированный но тем не менее.
В результате у вас затык на пустом месте, когда LA системы 5 I-O 10% sql=100% на 1 камне.
Как правило ситуация дальше осложняется по следующей схеме
занимаются все камни тяжелыми хитами, тем более с каждым разом это становится легче, поскольку ресурсы других камней уже заняты, в результате раз в день база начинает тормозить, и ее рестартуют по крону.
;)))
Но все индивидуально.
Ответ написан
SilenceOfWinter
@SilenceOfWinter
та еще зажигалка...
ко всему выше сказанному добавлю, что нагрузка может возникать не в текущей задаче, а в выполняемых параллельно (например, запущен какой-то ресурсоемкий процесс вроде бекапа или индексирования) т.ч. надо учитывать серверную нагрузку на момент запуска задачи.
Ответ написан
@vitaly_il1
DevOps Consulting
сервер: 2 x 2.8 ГГц, оперативка 4 гб, NVMe 50 ГБ (заполнено 13 гб)

А какой размер самой базы?
И сколько использует MySQL?
Много записей?

Логгирование медленных запросов в БД - пусто.
- Логгирование медленных скриптов в php-fpm - пусто.

А вы уверены что mysql slow query log действительно работает?
Можно включить логирование времени на каждый запрос в nginx.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы