Метрики производительности Linux: на что смотреть в первую очередь

С чего начать проверку производительности Linux под нагрузкой

Быстрый triage Linux-хоста начинается с сопоставления load average и числа логических CPU. Затем проверьте загрузку каждого ядра, разложение CPU-времени на user, system, irq, softirq, iowait и steal. После этого сопоставьте признаки ожидания с PSI и показателями дисков.

Практический маршрут выглядит так: uptime или cat /proc/loadavg, затем mpstat -P ALL 1, vmstat 1, cat /proc/pressure/* и iostat -xz 1. Снимайте несколько последовательных выборок с одинаковым интервалом. Один высокий показатель задает направление проверки, но не доказывает причину деградации.

PSI показывает, сколько времени задачи теряют из-за нехватки CPU, памяти или I/O. Поля some и full помогают отделить частичную конкуренцию за ресурс от состояния, когда продвижение задач практически полностью остановилось. Для дисков смотрите IOPS, throughput, await, aqu-sz и %util, а вывод связывайте с latency приложения.

Минимальный алгоритм первичного triage

1. Зафиксируйте симптом. Запишите время начала, длительность, ошибки и latency сервиса. Отдельно отметьте, нагрузка постоянная или возникает короткими всплесками.
2. Снимите load average. Используйте uptime, w или cat /proc/loadavg. Одновременно выполните nproc, чтобы знать число доступных логических CPU.
3. Проверьте ядра. Запустите mpstat -P ALL 1 и найдите ядро с высоким user, system, irq, softirq, iowait или steal.
4. Проверьте общую картину. Команда vmstat 1 показывает очередь runnable-задач, блокировки, swap и долю ожидания I/O. Смотрите минимум 5-10 строк, а не первый снимок.
5. Проверьте PSI. Прочитайте /proc/pressure/cpu, /proc/pressure/memory и /proc/pressure/io. Сопоставьте рост avg10 с моментом деградации.
6. Перейдите к устройствам. Выполните iostat -xz 1. Проверьте отдельные диски, очереди, задержки, операции чтения и записи.
7. Найдите процессы и потоки. Используйте top -H, pidstat -u -t 1 и pidstat -d 1. После локализации ресурса сравните его с метриками приложения.

Какие выводы нельзя делать по одной цифре

• Load average 8 на сервере с 8 логическими CPU и load average 8 на сервере с 32 CPU описывают разную степень загрузки.
• Высокий load не означает автоматически, что процессор занят вычислениями. В него попадают задачи в непрерываемом ожидании, например из-за I/O.
• Высокий iowait не доказывает неисправность диска. Причиной могут быть NFS, RAID, виртуальный блочный слой, синхронные операции приложения или особенности учета CPU-времени.
• Низкая средняя загрузка CPU не исключает перегрузку одного ядра, CPU quota контейнера, короткий пик или высокую задержку памяти.
• Высокая пропускная способность диска может быть штатной при последовательной обработке больших файлов. Проблема подтверждается ростом latency, очереди, PSI io или задержки приложения.

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

Load average в Linux: что это и как читать

Load average показывает среднее число задач, которые готовы выполняться или находятся в состоянии непрерываемого ожидания. В Linux в расчет обычно попадают runnable-задачи и процессы в состоянии D, часто связанном с ожиданием I/O. Поэтому load average описывает очередь работы шире, чем загрузка CPU в процентах.

Значения обычно видны в трех временных окнах: 1, 5 и 15 минут. Их можно получить через uptime, w, top или файл /proc/loadavg. В последнем выводе после трех средних значений есть сведения о runnable и общем числе задач, а последним полем идет PID недавно созданного процесса.

Почему load average нужно сопоставлять с числом логических CPU

Для первичной оценки разделите load average на число доступных логических CPU. Например, load 4 на машине с 4 логическими CPU означает, что очередь работы сопоставима с вычислительной емкостью хоста. Load 4 на машине с 16 CPU дает значительно больший запас, если остальные показатели не указывают на I/O или память.

Значение около числа CPU может говорить об отсутствии запаса по вычислительному ресурсу. Это рабочий ориентир, а не универсальный порог. Окончательный вывод требует проверки CPU PSI, очереди runnable-задач, долей user и system, состояния I/O и latency сервиса.

Сравнение только с числом 1 приводит к ошибкам. На восьмиядерном сервере load 2 не означает ту же нагрузку, что на однопроцессорной виртуальной машине. В контейнере дополнительно учитывайте CPU quota: хост может быть свободен, пока процесс упирается в ограничение своей группы.

Что означают значения за 1, 5 и 15 минут

• 1 минута. Быстрее реагирует на текущий всплеск и подходит для первичной проверки инцидента.
• 5 минут. Показывает, сохраняется ли нагрузка после первых минут работы.
• 15 минут. Помогает увидеть устойчивый тренд, но сглаживает короткие пики.

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

Средние значения не показывают точную форму пика. Сервис может получать задержку 3 секунды в течение 10 секунд, а затем работать нормально. За 15 минут такой эпизод почти растворится, поэтому во время инцидента нужны выборки с интервалом 1-5 секунд и метрики latency.

Когда высокий load связан не с CPU

Высокий load при умеренном CPU часто связан с задачами в состоянии D. Они ждут завершения операции, но планировщик не может прервать такое ожидание обычным способом. Возможные направления проверки включают локальный диск, RAID, dm-crypt, сеть, NFS, зависший блочный слой и драйвер.

Связку проверяйте по нескольким признакам: растет ли iowait, увеличивается ли PSI io, есть ли очередь и задержка в iostat, какие процессы создают операции чтения и записи. Для поиска задач в непрерываемом сне подойдет команда:

ps -eo state,pid,ppid,comm,wchan:32 --sort=state

Процесс в состоянии D еще не означает поломку диска. Например, NFS-сервер может отвечать с задержкой, а локальный диск при этом останется исправным. Имя устройства и путь операции нужно подтвердить на уровне приложения и блочного стека.

Загрузка по ядрам Linux: как найти локальное узкое место

Агрегированная загрузка CPU скрывает распределение работы. Однопоточное приложение способно занять одно ядро на 100%, пока остальные ядра простаивают. На сервере с 8 логическими CPU такой процесс иногда дает около 12,5% суммарной загрузки, хотя его собственная задача уже уперлась в предел одного потока.

Почему средняя загрузка CPU может выглядеть нормально

Средняя загрузка складывается по доступным CPU. Если один поток выполняет криптографию, компиляцию, обработку запроса или JavaScript, остальные ядра не смогут ускорить его без параллелизации. Аналогичная картина возникает при CPU affinity, pinning, ограничении контейнера или неравномерном распределении IRQ.

Проверку начните с:

mpstat -P ALL 1

Строка all показывает среднее по CPU, а строки отдельных ядер помогают увидеть локальное узкое место. Ищите ядро, на котором idle почти исчез, а user или system заметно выше соседних значений. Снимите несколько интервалов, поскольку короткий поток может менять ядро между выборками.

Что означает system, irq и softirq

• user. Время пользовательского кода, включая процессы и потоки приложений.
• system. Время работы ядра по запросам процессов: системные вызовы, управление памятью, файловая система и другие операции.
• irq. Обработка аппаратных прерываний.
• softirq. Отложенная обработка событий ядром, часто связанная с сетью и I/O.
• iowait. Время, когда CPU не выполняет пользовательскую или системную работу и в системе есть незавершенные операции I/O.
• steal. Время виртуального CPU, которое гипервизор отдал другой работе.
• idle. Время без выполняемой задачи.

Высокий system может указывать на интенсивные системные вызовы, копирование данных, работу файловой системы или reclaim памяти. Высокие irq и softirq требуют проверки сетевого трафика, дисковых контроллеров, драйверов и распределения прерываний. Такие значения задают гипотезу, а не готовое объяснение.

Как связать горячее ядро с конкретным процессом

Команда top -H раскрывает потоки процесса. Для выборки CPU по процессам и потокам используйте:

pidstat -u -t 1

Сопоставьте TID горячего потока с процессом, контейнером и типом работы. Затем проверьте affinity:

taskset -pc PID
cat /proc/PID/status | grep Cpus_allowed_list

При контейнерной нагрузке проверьте CPU quota и throttling в cgroup. При виртуализации сравните vCPU, steal и лимиты платформы. Настройки affinity и IRQ меняйте после фиксации причины, иначе можно перенести очередь на другое ядро и усложнить диагностику.

iowait и steal: признаки ожидания, а не готовый диагноз

iowait и steal показывают, что CPU-время связано с ожиданием или внешним планированием. Эти поля полезны как часть временного ряда. Процент, снятый одним мгновенным экраном, не описывает длительность события и влияние на пользовательские запросы.

Как читать iowait без типичной ошибки

iowait растет, когда CPU простаивает при наличии незавершенного I/O. Это не эквивалент сообщения «диск медленный». Один и тот же iowait может возникнуть при разной интенсивности запросов, разном числе CPU, синхронной работе приложения, сетевой файловой системе или виртуальном хранилище.

Проверяйте iowait вместе с:

• PSI io, чтобы увидеть потерю времени задачами;
• await, чтобы оценить среднюю задержку операций;
• aqu-sz, чтобы увидеть накопленную очередь;
• %util, чтобы оценить занятость устройства;
• r/s, w/s, rkB/s и wkB/s, чтобы определить профиль нагрузки;
• latency приложения и активными процессами, чтобы понять пользовательский эффект.

Высокий iowait при низких await и aqu-sz может быть связан с большим количеством блокирующих операций небольшого размера или с особенностями учета. Высокий iowait вместе с растущей очередью и задержкой дает более сильный сигнал проблемного I/O.

Что показывает steal в виртуальной машине

Steal показывает время, когда гостевая операционная система хотела выполнять работу, но гипервизор не предоставил виртуальному CPU физическое время. Причиной бывает конкуренция за физические ядра, лимит CPU, oversubscription или временная нагрузка на узле.

Типичный признак: в гостевой системе user и system не выглядят предельными, но сервис отвечает медленно, растет steal и одновременно повышается CPU pressure. На bare metal steal обычно близок к нулю. Виртуальная машина требует проверки размера vCPU, лимитов, типа инстанса и метрик гипервизора.

Для рабочих нагрузок, где задержка критична, сравните одинаковые интервалы на нескольких виртуальных машинах и в разные часы. Постоянный высокий steal и краткие всплески требуют разных действий. В первом случае проверяйте класс ресурсов и размещение, во втором ищите конкурирующую нагрузку или периодические задачи.

Для тестов, где нужен повторяемый профиль виртуальных ресурсов, можно использовать облачную инфраструктуру Timeweb Cloud с выбором VDS, хранилища и других компонентов. Сравнивайте результаты только при одинаковом профиле нагрузки, размере диска и параметрах виртуальной машины.

Комбинации метрик для разделения CPU, I/O и виртуализации

Корреляция должна сохраняться во времени. Если два показателя выросли в одну секунду случайно, этого мало. Повторите измерение во время симптома и сравните с нормальным периодом.

PSI Linux: что это и почему он полезнее одной загрузки

Pressure Stall Information показывает долю времени, в течение которой задачи не могли продвигаться из-за конкуренции за ресурс. Утилизация отвечает на вопрос «насколько занят ресурс», а PSI дополнительно показывает «сколько времени из-за этого теряют задачи».

На уровне хоста данные читаются из файлов:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Строки содержат окна avg10, avg60, avg300 и накопительный счетчик total. Средние значения выражают процент времени давления за 10, 60 и 300 секунд. total накапливается с момента запуска учета и удобен для расчета дельты в системе мониторинга.

CPU pressure: есть ли конкуренция за процессор

CPU PSI с полем some растет, когда хотя бы часть runnable-задач вынуждена ждать CPU. Чем выше значение в окне avg10, тем больше времени задачи теряют в коротком интервале. Сопоставьте его с загрузкой по ядрам, run queue из vmstat, user, system и ограничениями cgroup.

Для CPU строка full обычно отсутствует или не используется, поскольку состояние, когда все задачи одновременно не получают CPU, трактуется иначе, чем полная блокировка памяти или I/O. Не считайте отсутствие CPU full доказательством отсутствия CPU-дефицита.

Memory pressure: когда память становится причиной задержек

Memory PSI показывает, сколько времени задачи теряют из-за нехватки доступной памяти и операций reclaim. Рост memory pressure может сопровождаться сканированием страниц, очисткой кешей, записью dirty pages, swap и резким увеличением latency.

Свободная память сама по себе не исключает давление. Linux использует RAM для кеша, а приложение может упираться в cgroup limit, NUMA-узел или медленный reclaim. Сопоставьте PSI memory с vmstat 1:

• si и so показывают обмен страниц со swap;
• r отражает очередь runnable-задач;
• b показывает заблокированные задачи;
• изменения памяти и кешей помогают понять, что именно происходило во время пика.

Высокий memory PSI при нулевом swap все равно требует проверки. Давление может возникать до активной записи страниц на диск, особенно при жестком лимите контейнера или нехватке памяти для конкретной группы.

I/O pressure и различие some и full

some показывает интервалы, когда хотя бы часть задач не могла продвигаться из-за ожидания ресурса. full отражает интервалы, когда все отслеживаемые не простаивающие задачи одновременно оказались в таком ожидании. Для memory и io высокий full означает более тяжелую блокировку выполнения.

Пример чтения:

cat /proc/pressure/io

Если растут some и full в io, а await и очередь устройства увеличиваются в тот же момент, влияние дисковой подсистемы подтверждается сильнее. Если PSI io растет без заметной активности локальных устройств, проверяйте NFS, сетевые блочные устройства, FUSE, виртуальный диск и процессы, ожидающие внешнюю систему.

PSI доступен в ядрах и конфигурациях, где включен соответствующий механизм. В контейнере путь к данным и набор доступных файлов зависят от версии ядра и настроек cgroup. Отсутствие файла нужно отличать от нулевого давления.

Дисковая подсистема: какие показатели смотреть после iowait

После сигнала iowait или PSI io переходите от CPU к конкретным устройствам. Основная команда для такой проверки:

iostat -xz 1

Ключи -x включают расширенную статистику, а -z скрывает устройства без активности. Опция 1 задает интервал в одну секунду. Первый блок вывода содержит средние значения с момента загрузки и часто плохо подходит для инцидента, поэтому анализируйте следующие строки.

Подробный разбор IOPS, latency, throughput, RAID и файловых систем есть в руководстве по влиянию дисков и файловых систем на скорость сервера.

await, aqu-sz и %util: как читать задержку и очередь

Универсального значения await для всех систем нет. Для HDD, SATA SSD, NVMe, RAID, dm-crypt и виртуального диска нормальные задержки различаются. Сравнивайте результат с baseline конкретного устройства и требованиями приложения.

%util, близкий к 100%, показывает постоянную занятость устройства. Для SSD и NVMe параллельные очереди могут обслуживаться одновременно, поэтому одно только значение %util не описывает полную сатурацию. Растущие await, aqu-sz и PSI io дают более содержательный сигнал влияния на задачи.

Как найти конкретное устройство и тип операции

Начните с карты блочных устройств:

lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS

Свяжите имя устройства из iostat с LVM, dm-crypt, RAID, файловой системой или виртуальным диском. Высокая задержка на верхнем устройстве может возникать ниже, например на физическом диске, RAID-массиве или удаленном хранилище.

Для поиска процессов, создающих I/O, используйте:

pidstat -d 1

Смотрите read и write rate, PID, имя процесса и момент роста задержек. Процесс с высокой скоростью записи не обязательно виноват в latency: небольшое число синхронных операций может создавать большую задержку при умеренном throughput.

При работе с контейнерами добавьте имя группы и лимиты I/O. В Kubernetes проверьте, какой pod создает операции, на каком узле он работает и не совпадает ли пик с журналированием, резервным копированием или compaction базы данных.

Почему высокая пропускная способность не всегда означает проблему

Throughput и IOPS описывают объем и количество операций, а latency показывает время ожидания конкретного запроса. Два профиля могут давать одинаковые 200 MB/s: последовательное чтение блоками большого размера и множество мелких случайных операций. Их влияние на очередь и задержку приложения будет разным.

Интенсивная фоновая запись может выглядеть нормально по throughput, пока интерактивные запросы сохраняют низкий await. Если одновременно растут очередь, PSI io и p95 latency, фоновая работа уже конкурирует с сервисом за устройство.

Оценивайте disk throughput вместе с размером блока, read/write ratio, IOPS, await, aqu-sz, %util и задержкой приложения. Метрики должны быть сняты в одном временном ряду, иначе связь между нагрузкой и симптомом остается предположением.

Как связать метрики и локализовать узкое место

Системная диагностика ускоряется, когда каждое наблюдение ведет к следующей проверке. Таблица ниже задает порядок действий, но не заменяет проверку на реальном хосте.

Высокий load average, CPU занят на всех ядрах

Проверьте, растет ли CPU PSI и увеличивается ли очередь runnable-задач. Если user преобладает, найдите горячие процессы и потоки. Если system, irq или softirq занимают значительную долю, изучите системные вызовы, сеть, драйверы и I/O.

После подтверждения вычислительной сатурации выбирайте действие по профилю задачи: уменьшить объем работы, распараллелить обработку, изменить CPU limit, добавить CPU или масштабировать сервис. Изменение планировщика без понимания потока нагрузки редко устраняет первопричину.

Высокий load average, CPU не полностью занят, растет iowait

Проверьте PSI io, await, aqu-sz, %util и тип операции. Если устройство не показывает активности, ищите сетевую файловую систему, удаленное хранилище, зависший mount или виртуальный слой.

Отдельно проверьте процессы в состоянии D и операции, которые ждут fsync. Приложение может создавать небольшое число синхронных запросов, но каждый запрос будет задерживать пользовательскую транзакцию.

Высокий load average в гостевой системе при высоком steal

Сначала отделите нагрузку внутри гостя от времени, которое забрал гипервизор. Проверьте, растет ли steal вместе с latency и CPU PSI, а не только в одном снимке top. Сравните период с обычным состоянием и с другими виртуальными машинами на той же платформе.

Постоянный steal требует проверки типа VM, размера vCPU, CPU limits и размещения. Кратковременный всплеск может совпадать с обслуживанием узла или временной конкуренцией. Гостевая система не всегда может подтвердить причину без данных гипервизора.

Нормальная средняя загрузка, но сервис отвечает медленно

Сократите интервал измерения и проверьте каждое ядро. Один горячий поток, короткая блокировка памяти, swap, I/O burst или CPU throttling контейнера могут не повлиять заметно на 5- и 15-минутные значения.

Сопоставьте системные выборки с p95 и p99 latency, временем запросов к базе данных, очередями и ошибками. Нормальный средний CPU при растущем p99 означает, что искать нужно по временным пикам и конкретным операциям.

Минимальный набор команд для мониторинга производительности Linux

Load average и число CPU

Первый снимок должен содержать время, load и число логических процессоров:

date
uptime
nproc
cat /proc/loadavg

uptime показывает load average в человекочитаемом виде. nproc сообщает число CPU, доступных текущему процессу. В контейнере это число может отличаться от общего числа ядер хоста. /proc/loadavg удобен для автоматического сбора, потому что формат стабилен для базового shell-скрипта.

CPU по ядрам и процессам

Для per-core статистики используйте:

mpstat -P ALL 1

Для потоков и процессов:

top -H
pidstat -u -t 1

В выводе ищите user, system, irq, softirq, iowait, steal и idle. У top первый экран может отражать усреднение с момента запуска процесса, поэтому интерактивно дождитесь обновления или используйте пакетную выборку с несколькими итерациями.

PSI и диски

Снимите PSI по всем трем ресурсам:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Общую картину памяти, очередей и swap покажет:

vmstat 1

Расширенную статистику устройств и процессы с I/O соберут:

iostat -xz 1
pidstat -d 1

Команды mpstat, iostat и pidstat обычно входят в пакет sysstat. vmstat часто поставляется с procps или procps-ng. Названия столбцов, доступность PSI и отдельные поля зависят от версии ядра, sysstat и параметров сборки.

Как снимать показатели для сравнения

Снимайте минимум 5-10 последовательных строк с интервалом 1 секунда для оперативного triage. Для устойчивого тренда используйте более длинное окно и сохраненный временной ряд. В каждом наборе фиксируйте:

• время и длительность замера;
• тип нагрузки приложения и число запросов;
• число доступных CPU и лимиты контейнера или VM;
• load average, per-core CPU, PSI и дисковые показатели;
• ошибки, latency и фоновые задачи, например backup или compaction.

Для короткой записи в файл можно использовать:

timeout 60 mpstat -P ALL 1 > mpstat.log

Не смешивайте данные, снятые во время простоя и под нагрузкой. Сначала соберите baseline в штатном режиме, затем повторите те же измерения во время симптома. Это позволит отличить аномалию от обычного рабочего профиля.

Типичные ошибки при чтении метрик Linux

Универсальных порогов для всех серверов нет

Нормальные значения зависят от CPU, числа потоков, типа накопителя, RAID, файловой системы, гипервизора и характера нагрузки. Для одного сервиса await 5 мс может быть нормой, для другого уже создавать задержку. Ориентируйтесь на baseline, SLA и фактическую latency.

При сравнении серверов учитывайте одинаковые условия: размер блока, read/write ratio, число запросов, кеширование, объем памяти и лимиты CPU. Число без контекста не дает надежной оценки.

Практический подход к сбору baseline и проверке CPU, RAM, дисков, сети и latency описан в руководстве по оценке производительности системы.

Среднее значение скрывает пики

Окна 5 и 15 минут сглаживают короткие события. Краткая блокировка, burst I/O и перегрузка одного ядра могут исчезнуть в среднем значении. Для инцидента используйте короткий sampling interval, а для планирования ресурсов храните длинный временной ряд.

Связывайте timestamp метрик с ошибками и latency. Если p99 растет в 12:01:15, проверьте PSI, CPU и диски в тот же момент. Среднее за час рядом с этой точкой недостаточно.

Метрика указывает направление, но не заменяет проверку причины

• CPU подтверждайте per-core статистикой, PSI, run queue и процессами.
• iowait подтверждайте PSI io, iostat, задержкой устройства и активными операциями.
• steal подтверждайте метриками гипервизора, лимитами и сравнением VM.
• memory pressure подтверждайте vmstat, swap, reclaim, cgroup и latency приложения.

Рабочий набор системных и прикладных метрик для Linux, виртуальных машин, Docker, Kubernetes, NAS и ZFS собран в шпаргалке для DevOps-инженера и администратора.

Не сравнивайте load только с единицей, не трактуйте iowait как доказательство неисправности диска и не используйте %util как единственный признак насыщения SSD или NVMe. Проверяйте единицы измерения: проценты CPU, миллисекунды await, операции в секунду, KB/s и средний размер очереди описывают разные свойства системы.

Краткая шпаргалка: на что смотреть в первую очередь

Порядок проверки за несколько минут

1. Load average и CPU. Выполните uptime, nproc и cat /proc/loadavg. Сравните load с доступными логическими CPU.
2. Ядра. Запустите mpstat -P ALL 1. Если одно ядро занято, ищите поток через top -H и pidstat -u -t 1.
3. iowait и steal. Высокий iowait ведет к PSI io и iostat. Высокий steal ведет к проверке VM и гипервизора.
4. PSI. Прочитайте CPU, memory и io. Рост CPU some указывает на очередь CPU, memory pressure требует проверки reclaim и swap, io pressure ведет к устройствам и удаленным хранилищам.
5. Диски. Выполните iostat -xz 1. Сопоставьте r/s, w/s, throughput, await, aqu-sz и %util с типом устройства.
6. Процессы и приложение. Используйте pidstat -d 1, pidstat -u -t 1, логи и p95/p99 latency. Подтвердите, какой процесс создает нагрузку и как она влияет на запросы.

Узкое место подтверждается согласованным изменением нескольких метрик: системного сигнала, показателя ожидания, конкретного ресурса и latency приложения. Такой порядок сокращает число рискованных изменений во время инцидента.