Форум пользователей MySQL

Ситуация следующая:

linux, mysql 5.7, обслуживается база сайта с  высокой посещаемостью.
Помимо обработки запросов от пользователей сайта иногда по cron'у запускаются обсчеты (например, чистка мусора или денормализации).

И в эти моменты регулярно случается следующая история - некоторые запросы, которые должны летать со скоростью если не света, то хотя бы пули (например выборка по уникальному ключу из таблицы, в которой 20 записей и никаких CRUD-операций с ней не делается, это справочник) - начинают выполняться по 4-5 секунд.

# Query_time: 4.705879 Lock_time: 0.000054 Rows_sent: 1 Rows_examined: 1 Rows_affected: 0
# Bytes_sent: 844
SET timestamp=1588132866;
SELECT s.* FROM  s WHERE f = '918273e0-04e5-11e9-81cc-505056aa1bee'; //после f проиндексировано, в таблице 20 записей.


Далее, когда выполнение пресловутой "вредной" cron-операции заканчивается - ситуация нормализуется.

Такие реакции afaik случаются от всплеска context switches, но всплесков context swtiches во время такой проблемы сейчас нет.

Вопрос админо/devops характера - как можно такие вещи отслеживать?  atop? буфера какие-то в ОС? Как определить во что упираемся?
Поможет ли наращивание железа и если да, то какого..
Имеет ли смысл настроить pt-stalk и если настроить, то на какие триггеры?
В общем, прошу поделиться соображениями.

А то сейчас проблему видно только вот в таких тормозящих запросах - со временем та же таблица s может уехать в мемкеш и "критерий" исчезнет.