Как оценить производительность системы: ключевые метрики, методы и первые шаги

Производительность системы оценивают по тому, как она обрабатывает конкретную рабочую нагрузку. Для измерения нужны время отклика, пропускная способность, доля ошибок, состояние CPU, RAM, дисковой и сетевой подсистем. Одного процента загрузки процессора недостаточно: сервис может медленно отвечать при низком CPU из-за задержек диска, swap, сетевых потерь или блокировок.

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

Производительность связана с доступностью и надежностью, но не заменяет их. Доступный сервис может отвечать за 20 секунд, а надежный сервис может стабильно обрабатывать неверные запросы с высоким уровнем ошибок. Для полноценной оценки нужны пользовательские метрики и состояние инфраструктуры: latency, throughput, RPS, p95, p99, CPU utilization, load average, available RAM, swap, IOPS, await, packet loss и retransmissions.

Что означает производительность системы на практике

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

Оценка должна учитывать четыре группы признаков: результат для пользователя, загрузку вычислительных ресурсов, скорость хранения данных и качество сети. Метрики читают совместно и привязывают к нагрузке, версии ПО, конфигурации и времени события.

Производительность, задержка и пропускная способность: в чем разница

Latency, или время отклика, показывает, сколько времени занимает одна операция. Для HTTP-запроса это интервал между отправкой запроса и получением полного ответа. Для базы данных это длительность выполнения SQL-запроса. Для файлового сервера это время чтения или записи нужного блока.

Throughput, или пропускная способность, показывает объем работы за единицу времени. Для API используют RPS, для базы данных число транзакций в секунду, для хранилища IOPS и MiB/s, для сети Mbit/s или Gbit/s. Система может быстро обрабатывать один запрос и плохо работать при ста параллельных запросах, если очередь быстро растет.

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

• API: p95 latency 180 мс, throughput 450 RPS, error rate 0,2%.
• База данных: время выполнения запроса 40 мс, 1200 транзакций в секунду, очередь активных соединений 15.
• Файловый сервер: 18 тысяч IOPS при случайном чтении блоками 4 KiB или 600 MiB/s при последовательном чтении.
• Kubernetes-узел: 12 работающих pod, 6 vCPU, 18 GiB доступной памяти, нагрузка сети 1,2 Gbit/s.

Среднее время ответа скрывает редкие медленные операции. Если 99 запросов завершились за 50 мс, а один занял 10 секунд, среднее значение составит примерно 149,5 мс. Перцентиль p99 покажет хвост распределения и предупредит о проблеме точнее. Для пользовательских сервисов обычно сохраняют p50, p95 и p99, а выбор порога связывают с SLA и типом операции.

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

Загрузка CPU 100% может быть штатной, если throughput соответствует плану, p95 не растет, ошибок нет, а очередь задач остается предсказуемой. Фоновый расчет, кодирование видео или пакетная обработка часто используют все доступные ядра, и это не требует немедленного увеличения ресурсов.

Низкий CPU тоже не доказывает отсутствие проблемы. Процесс может ждать диск, сетевой ответ, блокировку или свободное соединение в пуле. Виртуальная машина способна простаивать из-за steal time, когда гипервизор не предоставляет ей виртуальный процессор. Контейнер может упираться в лимит cgroup, хотя суммарная загрузка хоста остается невысокой.

Признак насыщения ресурса появляется, когда дальнейший рост нагрузки увеличивает задержку, очереди или ошибки. Запас производительности виден по тому, сколько дополнительной работы система принимает без заметного ухудшения p95 и p99. Поэтому высокий процент нужно сопоставить с объемом работы и результатом для клиента.

Для первичной проверки Linux-сервера пригодятся команды top, vmstat, pidstat, iostat и ss. Пошаговый алгоритм с этими инструментами собран в статье о поиске узкого места на сервере.

Ключевые метрики производительности: что измерять на каждом уровне

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

Сервисные метрики: время ответа, RPS и ошибки

Сервисные метрики показывают, что получает пользователь или зависимая система. Минимальный набор включает:

• Latency: среднее время ответа, p50, p95 и p99.
• RPS или throughput: число запросов, задач, транзакций или сообщений за секунду.
• Error rate: доля ответов с ошибками, отказов, повторных попыток и таймаутов.
• Concurrency: число одновременных запросов, активных соединений или задач.
• Размер операции: объем ответа, размер файла, число строк в выборке или размер сообщения.

Метрики нужно разбивать по endpoint, типу операции, коду ответа, клиенту и зависимости. Средний latency всего API может выглядеть нормальным, если медленные запросы составляют небольшую долю. При этом один endpoint с p99 в 8 секунд будет терять пользователей и создавать повторные запросы.

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

Ресурсные метрики: CPU, RAM, диск и сеть

Эта таблица помогает связать показатель с вероятным симптомом:

Единичный снимок не дает надежного вывода. Значение 80% CPU может быть кратким всплеском или постоянной нагрузкой в течение часа. Метрики записывают с временной шкалой и связывают с RPS, размером операций, числом пользователей и изменениями в системе.

Насыщение, ошибки и запас ресурсов

Utilization показывает занятость ресурса, но не всегда показывает очередь. Для диска нужно смотреть utilization, await, queue depth и ошибки вместе. Для сети нужны bandwidth, drops, CRC-ошибки и retransmissions. Для памяти важны available, swap, major page faults и признаки memory pressure.

Одинаковая загрузка может означать разный запас. Сервер при 70% CPU способен обслуживать 100 RPS с p95 100 мс, а при той же загрузке и 300 RPS уже может держать очередь и отвечать за 2 секунды. Поэтому показатель насыщения нужно измерять вместе с входящей нагрузкой.

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

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

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

Сначала описать сценарий и критерий проблемы

Фраза «сервер тормозит» слишком общая. Запишите проверяемое утверждение:

• какой сервис затронут;
• какая операция замедлилась;
• кто наблюдает проблему, пользователь, другой сервис или фоновая задача;
• в какое время началась деградация и как долго длится;
• какой объем нагрузки проходил в этот период;
• какое значение считается нормальным и какое значение нарушает договоренность.

Пример хорошей формулировки: «После 14:20 p95 запроса к endpoint поиска вырос с 240 мс до 1,8 секунды при увеличении нагрузки с 180 до 260 RPS, доля ответов 5xx достигла 1,4%». Такая запись направляет диагностику и помогает выбрать контрольный замер.

Критерием может быть latency, throughput, error rate, время выполнения резервной копии или скорость обработки очереди. Процент CPU сам по себе редко подходит как критерий проблемы.

Какие данные собрать на сервере и в сервисе

Для Linux-сервера соберите показатели минимум за нормальный и проблемный периоды:

• top или htop для процессов, CPU, RAM и load average;
• vmstat 1 10 для run queue, памяти, swap и iowait;
• pidstat -u -r -d 1 10 для CPU, памяти и дисковой активности процессов;
• iostat -xz 1 10 для IOPS, throughput, await, очередей и utilization устройств;
• sar -n DEV 1 10 для трафика и ошибок сетевых интерфейсов;
• ss -s и ss -tanp для состояния TCP-соединений, очередей и проблем с соединениями.

На уровне приложения сохраните RPS, p50, p95, p99, ошибки, таймауты, размер запросов и состояние пулов соединений. Для процесса или контейнера нужны лимиты CPU и памяти, фактическое потребление, throttling и перезапуски. В Kubernetes добавьте состояние pod, события scheduler, рестарты, requests, limits и сетевые ошибки.

В журнал диагностики включите логи приложения, события деплоя, изменения конфигурации, обновления ядра и пакетов, фоновые задачи, backup, scrub, autoscaling и состояние зависимостей. Для централизованного наблюдения подходят Prometheus, node_exporter и Grafana. Метрики должны иметь единые временные метки, иначе корреляция событий будет неточной.

Как построить baseline и сравнить периоды

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

1. Выберите нормальный интервал, например 30 минут стабильной работы.
2. Зафиксируйте проблемный интервал с началом и окончанием деградации.
3. Сохраните версии ОС, приложения, ядра, драйверов и конфигурацию лимитов.
4. Поставьте на одну временную шкалу p95, RPS, ошибки, CPU, RAM, I/O и сеть.
5. Отметьте деплои, изменения схемы базы данных, backup, scrub, миграции и сетевые события.

Короткий замер в 10 секунд может показать случайный всплеск. Для инцидента используйте данные с шагом, который позволяет увидеть его начало, а для планирования ресурсов храните историю за недели. Нагрузочный тест в production запускайте только после согласования, с ограничением RPS, отдельным окном и готовым rollback.

Загрузка CPU и RAM: мониторинг и оценка использования ресурсов

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

Как интерпретировать загрузку CPU

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

Смотрите загрузку отдельных ядер. Средние 50% по 16 vCPU могут скрывать одно ядро со 100% загрузкой и очередь на однопоточную операцию. Для базы данных, event loop и некоторых системных обработчиков это критично.

Load average показывает число задач, которые ждут выполнения или завершения I/O. Сравнивайте его с числом логических CPU. Load 8 на сервере с 8 CPU требует проверки очереди, а на сервере с 32 CPU может быть штатным значением. Высокий load при низком CPU часто связан с диском или блокировками.

При подозрении на CPU проверьте:

• какие процессы и потоки потребляют ресурс через top -H и pidstat -u;
• есть ли throttling CPU у контейнера;
• не выросла ли стоимость операции после деплоя;
• не изменился ли объем входящих запросов или размер данных;
• не увеличился ли steal time на виртуальной машине.

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

Поле used в выводе free -h не дает полного ответа. Linux использует свободную RAM для page cache и может быстро освободить часть этой памяти при необходимости. Для первичной оценки смотрите available, swap и динамику reclaim.

free -h
vmstat 1 10
cat /proc/pressure/memory

Дефицит памяти вероятен, если available стабильно снижается, растет swap in/out, увеличиваются major page faults и memory pressure, а latency меняется одновременно с этими событиями. При активном swap процесс получает страницы с задержкой диска, поэтому внешне проблема может выглядеть как дисковая.

Проверьте OOM-killer через журнал ядра и состояние контейнеров. В Docker и Kubernetes лимит памяти может сработать раньше, чем закончится RAM хоста. Для процесса с резким ростом памяти соберите рабочую выборку, частоту сборки мусора, число открытых файлов и историю перезапусков.

Что проверить при одновременной нагрузке CPU и RAM

Одновременный рост CPU и потребления RAM бывает следствием увеличения рабочей выборки, утечки памяти, частой сборки мусора или роста очереди запросов. Сначала определите процесс, затем сопоставьте его потребление с RPS и p95.

1. Сравните размер процесса и контейнера с baseline.
2. Проверьте лимиты cgroup и признаки CPU throttling.
3. Сопоставьте рост RAM с количеством запросов и размером данных.
4. Проверьте swap, OOM-события и частоту сборки мусора.
5. Повторите измерение после изменения только одного параметра.

Увеличение CPU или RAM без подтвержденного узкого места может лишь перенести задержку на диск, сеть или зависимый сервис. Сначала сохраните профиль процесса и метрики, затем выбирайте между изменением кода, лимитов, размера экземпляра и архитектуры нагрузки.

Мониторинг дисковой подсистемы: как проверить состояние диска сервера

Диск влияет на latency через скорость операции, глубину очереди, кэш и ошибки. Проблема может быть связана с нехваткой места, деградацией накопителя, неудачным профилем I/O или фоновой задачей на массиве.

Метрики I/O: IOPS, throughput, await и очередь

IOPS показывает число операций ввода-вывода за секунду. Throughput показывает объем переданных данных, например MiB/s. Диск, который выдает 80 MiB/s при последовательном чтении, может обрабатывать намного меньше случайных операций блоками 4 KiB.

Await отражает среднюю задержку I/O вместе с ожиданием в очереди. Queue depth показывает накопившиеся запросы. Utilization показывает занятость устройства, но высокий процент нужно связывать с latency и фактической нагрузкой.

iostat -xz 1 10
pidstat -d 1 10
lsblk -o NAME,TYPE,SIZE,MODEL,MOUNTPOINT

Рост p95 сервиса вместе с iowait, await, blocked processes и queue depth указывает на дисковую гипотезу. Проверьте, какой процесс создает I/O, какой тип операций преобладает и не выполняются ли backup, scrub, resilver или массовая индексация.

Формулы и примеры расчета IOPS, throughput и задержек для баз данных и виртуальных машин приведены в руководстве по расчету производительности СХД.

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

Начните с информационной проверки, которая не записывает данные на устройство. Для SATA и SAS используйте SMART, для NVMe, журнал устройства и команду nvme smart-log. Проверяйте переназначенные сектора, pending sectors, ошибки интерфейса, температуру, media errors, процент износа SSD и число небезопасных отключений.

smartctl -a /dev/sdX
nvme smart-log /dev/nvme0
journalctl -k | grep -Ei error
dmesg | grep -Ei error

Состояние диска оценивают вместе с журналом ядра и счетчиками ошибок. Один атрибут SMART не заменяет диагностику массива. Если накопитель деградирует, сначала проверьте резервную копию и план замены, затем выбирайте self-test с учетом политики эксплуатации.

Для ZFS используйте zpool status, проверяйте ошибки чтения, записи и checksum, состояние vdev и историю scrub. Scrub читает данные со всего пула и создает дополнительную нагрузку, поэтому его время выбирают с учетом рабочего графика и запаса производительности. Тесты записи и fio на рабочем хранилище без согласования могут уничтожить данные или вызвать заметную деградацию.

Особенности NAS, RAID и ZFS

Одинаковый показатель MiB/s имеет разный смысл для RAID10, RAID5, RAIDZ и одиночного SSD. Случайная запись, последовательное чтение и синхронная запись создают разные профили нагрузки. Размер блока приложения, stripe, кэш контроллера и тип дисков меняют результат.

Для NAS и ZFS отдельно учитывайте:

• тип vdev и число дисков;
• профиль чтения и записи;
• sync writes и наличие корректного SLOG;
• размер ARC и давление на RAM;
• текущие scrub, resilver и другие фоновые операции;
• свободное место и фрагментацию;
• ошибки checksum, чтения и записи.

Универсальный порог await или utilization для всех NAS не существует. Сравнивайте значения с baseline конкретного массива и с latency операции, которую видит приложение. При выборе облачной инфраструктуры для временного нагрузочного стенда параметры CPU, диска и сети удобно контролировать отдельно, например в Timeweb Cloud.

Задержки и пропускная способность сети: как измерить

Сетевая диагностика должна разделять путь между узлами, состояние интерфейсов и работу приложения. Быстрый порт не гарантирует низкую задержку, а успешный ping не подтверждает отсутствие проблем в TCP или на уровне API.

Задержка, потери пакетов и нестабильность маршрута

RTT показывает время прохождения пакета туда и обратно. Packet loss показывает долю потерянных пакетов. Jitter описывает колебания задержки. Для пользовательского сервиса сохраняйте p95 и p99 latency, потому что средний RTT скрывает редкие скачки.

ping -c 20 server.example
mtr -rwzc 100 server.example

В рабочей команде замените имя узла на фактический адрес сервиса. Проверяйте путь в обе стороны, если это возможно. ICMP может ограничиваться на маршрутизаторе, поэтому потеря ответов ping не всегда означает потерю трафика приложения. Подтвердите гипотезу TCP-метриками, логами и задержкой реального запроса.

Как измерить реальную пропускную способность

Для контролируемого теста используют iperf3 между согласованными узлами. Зафиксируйте направление, длительность, число потоков, MTU, маршрут и время теста. Один TCP-поток и несколько потоков дают разные результаты, поэтому сравнивайте одинаковые параметры.

iperf3 -s
iperf3 -c 192.0.2.10 -t 30 -P 4
iperf3 -c 192.0.2.10 -t 30 -P 4 -R

Результат сопоставьте с нагрузкой интерфейса, CPU, диском и ограничением канала. Если iperf3 показывает 9 Gbit/s, а приложение передает 100 MiB/s, узкое место может находиться в диске, протоколе, шифровании, размере запросов или коде сервиса. iperf3 измеряет сеть между узлами и не заменяет тест реального сценария.

Ошибки интерфейса, drops и retransmissions

Проверьте ошибки и drops на физическом интерфейсе, порту коммутатора, виртуальном интерфейсе и bridge. Сверьте negotiated speed и duplex. CRC-ошибки, carrier errors, drops и рост TCP retransmissions могут объяснять таймауты при нормальной загрузке CPU.

ip -s link
ethtool eth0
ss -ti

В Docker и Kubernetes добавьте проверки overlay-сети, conntrack, MTU, сетевых политик, CNI и ограничений узла. Несовпадение MTU может повреждать крупные пакеты или вызывать фрагментацию, тогда как короткий ping будет проходить успешно.

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

Фактическое узкое место подтверждается связью между симптомом, нагрузкой и состоянием ресурса. Высокий показатель сам по себе остается гипотезой. Ищите момент, когда ресурс приблизился к насыщению, выросла очередь или появились ошибки, а latency и throughput изменились в том же сценарии.

Матрица симптомов и вероятных причин

Проверяйте гипотезу на уровне процесса, контейнера, конкретной операции или зависимости. Хостовая метрика может скрыть проблему одного pod, одного диска или одного endpoint.

Как читать метрики на общей временной шкале

Сначала найдите момент начала роста p95 или p99. Затем сравните его с RPS, ошибками, очередью CPU, iowait, available RAM, swap, await, retransmissions и событиями инфраструктуры. Если задержка выросла раньше CPU, процессор может быть следствием накопившейся очереди, а не первопричиной.

Отметьте изменения, которые произошли рядом по времени: деплой, обновление конфигурации, миграцию схемы базы данных, запуск backup, scrub, autoscaling, изменение маршрута или сетевые ошибки. Корреляция по времени сужает поиск, но причинную связь нужно подтвердить повторным наблюдением или контролируемым тестом.

При поиске узкого места полезно двигаться по цепочке: пользовательский запрос, endpoint, приложение, пул соединений, база данных, диск или сеть. Для сложных сервисов добавьте трассировки и профилирование. Они показывают, на каком вызове тратится время, когда системные метрики не дают достаточной детализации.

Типичные ошибки диагностики

• Смотреть только средние значения и пропускать p95, p99 и хвост задержек.
• Делать вывод по одному короткому замеру без baseline.
• Сравнивать разные типы нагрузки, размеры операций и периоды.
• Игнорировать данные per-process, per-container и per-endpoint.
• Запускать fio, массовый benchmark или iperf3 на production без согласования.
• Менять несколько параметров одновременно и терять возможность оценить эффект.
• Не фиксировать исходную конфигурацию, версии и критерий успеха.
• Считать высокий utilization причиной, не проверив latency, очередь и входящую нагрузку.

Нагрузочные тесты проводите на стенде или в отдельном окне с лимитами. Особенно осторожно работайте с тестами записи на NAS, RAID и ZFS: они способны вытеснить кэш, заполнить пул и ухудшить работу production.

Первые шаги после оценки: план действий и контроль результата

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

Порядок действий при первичной диагностике

1. Определите операцию и период. Запишите endpoint, задачу, узлы, время начала и нормальное значение.
2. Проверьте ошибки и доступность. Уточните коды ответов, таймауты, рестарты и состояние зависимостей.
3. Сопоставьте сервис и ресурсы. Сравните latency и throughput с CPU, RAM, диском и сетью.
4. Локализуйте компонент. Перейдите к процессу, контейнеру, устройству, интерфейсу или запросу.
5. Измените подтвержденный параметр. Выберите лимит, конфигурацию, размер ресурса или кодовую правку, которые связаны с симптомом.
6. Повторите измерение. Используйте тот же сценарий и сохраните показатели после изменения.
7. Подготовьте rollback. Зафиксируйте прежнюю конфигурацию и условие возврата, если latency, ошибки или стоимость вырастут.

Одна итерация должна отвечать на один вопрос. Если одновременно увеличить RAM, изменить настройки диска и включить кэш, итоговый эффект будет трудно объяснить, а побочный эффект можно пропустить.

Как понять, что оптимизация сработала

Сравнивайте одинаковые сценарии до и после изменения. Основные критерии:

• p95 и p99 latency снизились или вернулись к baseline;
• throughput вырос при сопоставимой нагрузке;
• доля ошибок и таймаутов не увеличилась;
• очереди CPU, диска и сети сократились;
• available RAM и swap остаются в штатном диапазоне;
• связанные сервисы не получили дополнительную нагрузку;
• стоимость инфраструктуры соответствует ожидаемому результату.

Проверяйте результат после окончания кратковременного пика. Улучшение в течение пяти минут не подтверждает решение, если через час снова растут очереди или заканчивается память. Сохраните графики до и после, запись изменения и версию конфигурации.

Минимальный постоянный мониторинг

Базовый dashboard сервера и сервиса должен включать:

• latency p95 и p99, RPS, throughput, ошибки и таймауты;
• CPU utilization, load average, run queue, iowait и steal;
• available RAM, swap in/out, memory pressure и OOM-события;
• IOPS, throughput диска, await, queue depth и utilization;
• bandwidth, packet loss, retransmissions, drops и ошибки интерфейсов;
• SMART или NVMe health, состояние RAID, vdev, scrub и resilver;
• события деплоя, изменения конфигурации, backup и фоновые задачи.

Алерты настраивайте по baseline и рабочему сценарию. Для одного сервиса критичен p99 выше 1 секунды, для другого такой порог допустим. График CPU без RPS не объясняет проблему, а алерт на disk utilization без await может создавать лишние срабатывания.

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

Рабочая схема оценки проста: зафиксируйте симптом, соберите baseline, измерьте сервис и ресурсы, найдите насыщение или ошибку, измените один подтвержденный фактор и повторите замер.

Для расширенной проверки автоматизированных систем пригодится руководство по latency, throughput, utilization, error rate и p95/p99. Материал помогает связать технические показатели с SLA, трассировками и реальными сценариями нагрузки.