Поиск узких мест по IO через eBPF (вместо iostat)

👁 Когда сервер начинает «тупить» по диску, большинство смотрит в iostat или top и делает выводы на глаз. Проблема в том, что эти инструменты дают агрегированную картину, но не показывают, какой процесс и какие операции реально создают задержки. Для точечной диагностики лучше использовать eBPF-инструменты.

📝 Поиск процессов с высокой задержкой IO через iotop и bpftrace

Если нужно быстро понять, кто занимает диск, но при этом не только по объёму, а по задержкам, можно использовать eBPF-скрипт для отслеживания latency блочных операций.

sudo bpftrace -e '
tracepoint:block:block_rq_complete
{
  @lat[comm] = hist(args->nr_sector);
}'

Этот пример строит гистограмму по операциям блочного устройства в разрезе процессов. Можно быстро увидеть, кто создаёт аномальную нагрузку или нестандартные паттерны IO.

📝 Анализ конкретного PID по системным вызовам

Когда подозреваешь конкретный сервис, полезно посмотреть, какие syscalls он реально делает и где залипает.

sudo strace -tt -T -p 12345

Флаги -tt -T показывают точное время и длительность каждого системного вызова. Если видишь длинные read() или fsync() — значит, проблема именно в IO, а не в CPU.

📝 Проверка dirty-памяти и writeback-поведения ядра

Иногда тормоза связаны не с самим диском, а с тем, как ядро сбрасывает грязные страницы. Проверить текущие параметры можно так:

sysctl vm.dirty_ratio
sysctl vm.dirty_background_ratio

Если значения слишком агрессивные для твоей нагрузки, сервис может периодически «подвисать» во время массового сброса данных на диск.

❗️ В проде важно не просто видеть, что «диск загружен», а понимать, кто и почему создаёт задержки. eBPF и точечная диагностика syscalls дают реальную картину, а не усреднённую температуру по больнице.

tags: #linux #мониторинг #диск

🧭 @recura_tech 🌐 VK 🌐 MAX