Какие утилиты использовать для проверки дисковой подсистемы и load average

Что проверяют

Отличаете ли вы симптом от причины: высокий load average сам по себе не говорит ни про процессор, ни про диск. Проверяют порядок действий на живой машине, а не умение перечислить команды. Уточняющий вопрос предсказуем: «LA равен 20, ваши следующие шаги».

Как отвечать

Начните с главного факта: в Linux load average считает не только процессы на процессоре, но и те, что в непрерываемом сне (состояние D), то есть ждут диск или сеть. Поэтому число сравнивают с количеством ядер (nproc) и никогда не читают в отрыве от других метрик.

• быстрый снимок: uptime или cat /proc/loadavg, затем top или htop, колонка wa и колонка b в vmstat 1;
• диск по устройствам: iostat -xz 1 из пакета sysstat. Смотрите r_await и w_await (латентность), aqu-sz (глубина очереди), rkB/s и wkB/s. Колонка %util на NVMe вводит в заблуждение: устройство обслуживает запросы параллельно, и 100% не означает предел;
• кто именно грузит: pidstat -d 1, iotop -o, для точечного разбора biolatency и biosnoop из bcc или свои скрипты bpftrace;
• место и inode: df -h и обязательно df -i, дальше du -xsh /* или ncdu. Если место «исчезло», ищите удалённые, но открытые файлы: lsof +L1;
• здоровье носителя: smartctl -a /dev/sda, для NVMe nvme smart-log /dev/nvme0n1;
• давление на ресурс: /proc/pressure/io и /proc/pressure/cpu (PSI) показывают, сколько времени задачи реально простояли в ожидании. Для контейнеров то же самое даёт cgroup v2 и io.stat.

Добавьте, что разовый замер не диагноз: нужны исторические графики (node_exporter с Prometheus, sar из sysstat) и сравнение с обычным профилем нагрузки этой машины.

Где спотыкаются

Читают LA как проценты загрузки процессора и пугаются числа, не спросив, сколько на машине ядер.

Останавливаются на df -h при жалобе «нет места», хотя кончились inode или файл удалён, а дескриптор держит живой процесс.

Считают %util доказательством перегрузки диска. На SSD и NVMe смотрят латентность и очередь, а ещё лучше сразу PSI.