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 камне.
Как правило ситуация дальше осложняется по следующей схеме
занимаются все камни тяжелыми хитами, тем более с каждым разом это становится легче, поскольку ресурсы других камней уже заняты, в результате раз в день база начинает тормозить, и ее рестартуют по крону.
;)))
Но все индивидуально.
