Имеем сервис: .net core, асинхронное (async/await) REST API которое читает/пишет из БД или кэша (Redis), фоновый обработчик на Hangfire, крутится на ubuntu.
Нагрузка слабая: ~4-7 rpc днем, по ночам падает до 0.1-1 rpc.
Есть логи и базовые метрики (память, cpu, кол-во запросов, время ответа и т.п.).
Память держится в пределах 40-100 Мб, треды — в пределах 8-12 штук.
95% по времени ответа ~10-50 мс (меряется именно время работы хендлера, без чтения/записи запроса/ответа).
Но, когда нагрузка спадает, то 99% начинает давать пики в 400-1200мс.
Заметна четкая корреляция с rpc: при штатной нагрузке отвечаем быстро, нагрузка ушла вниз и потом (спустя время) вверх — появляется пик.
Это буквально единичные запросы, ~0.2% от общей массы.
По логам они ничем не отличаются от обычных: sql запросы и чтение/запись из кэша отрабатывают так же быстро, как у остальных.
Было предположение, что дело в тред.пуле.
Типа когда нагрузка уходит, шедулер начинает прибивать лишние треды.
Соответственно, когда после понижения идет рост rpc, шедулеру нужно время на раскачку.
Подкрутил настройку minWorkerThreads в пуле, пики просадки стали чуть ниже — 300-700мс, но совсем не исчезли.
Не то, чтобы это было критично, но все же хочется убрать и эти 0.2% тормозов, т.к. объективных причин для них не видно.
Вот как бы их отследить, чтобы понять, в чем дело?
Что-то типа perfcollect/dotnet-trace collect, но не для всего подряд, а только для медленных запросов.
