Карта пределов вашего сервера за один вечер: набор замеров и таблица результатов

MAATRIX

Рано или поздно наступает момент, когда вопрос «а сервер вообще потянет?» перестаёт быть риторическим — растёт нагрузка, приближается сезонный пик, или вы просто впервые получили доступ к новой машине и хотите понимать, с чем работаете. Проблема в том, что «потянет» — это не одно число, а минимум шесть разных чисел: сколько ядер CPU реально доступно под нагрузкой, сколько памяти можно занять до свопа, сколько операций в секунду выдержит диск, какая пропускная способность у сети, сколько файловых дескрипторов и сколько соединений к базе данных сервер способен держать одновременно. Ниже — план на один вечер: какие замеры сделать, в каком порядке, какими командами, и как свести всё в одну таблицу, которая станет отправной точкой для планирования capacity.

Зачем нужна карта пределов, а не одна цифра

Типичная ошибка при оценке сервера — искать единственный «показатель мощности», по которому можно сравнивать конфигурации. На практике сервер почти никогда не упирается в один ресурс равномерно: под одной нагрузкой первым сдаётся CPU, под другой — диск, под третьей — количество соединений к базе, хотя формально «ресурсов много». Причина в том, что пределы независимы друг от друга и достигаются в разное время: CPU может простаивать на 20%, пока сеть уже захлёбывается в очереди пакетов, или наоборот — диск свободен, а упор в память приводит к свопу, который снаружи выглядит как «тормозит диск».

Карта пределов — это не разовое упражнение для галочки, а рабочий документ. Она нужна в трёх ситуациях: перед тем как взять сервер под конкретную нагрузку (чтобы понимать запас), после видимой деградации (чтобы быстро понять, в какой ресурс упёрлись, а не гадать), и периодически «на всякий случай», чтобы отследить, как со временем меняется профиль использования. Хорошая карта — это не абстрактные «сервер мощный», а таблица: ресурс, метод замера, текущее значение, практический потолок, дата замера. Именно к такой таблице мы идём.

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

Порядок замеров: план на вечер

Замеры имеют смысл в определённой последовательности — не потому что порядок физически важен, а потому что каждый следующий шаг проще интерпретировать, если предыдущий уже дал контекст. Разумный план на один вечер:

1. Инвентаризация (10 минут) — сколько ядер, сколько памяти, какой диск, какая сеть номинально доступны по документам провайдера или dmidecode/lscpu.
2. CPU и память в покое (15 минут) — базовая линия без нагрузки, чтобы отличить «уже занято системой» от «свободно для приложения».
3. Диск: IOPS и пропускная способность (30–40 минут) — самый долгий пункт, требует нескольких прогонов с разными паттернами.
4. Сеть (15–20 минут) — пропускная способность между вашим сервером и внешней точкой, задержка.
5. Файловые дескрипторы (10 минут) — системные и пользовательские лимиты, во что упирается конкретный процесс.
6. Соединения к базе данных (15–20 минут) — лимит СУБД и практический потолок до деградации.
7. Свод в таблицу (15 минут) — перенос всех цифр в единый формат.

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

CPU и память: быстрая базовая линия

Начните с того, что доступно без нагрузочного теста — это займёт минуты и сразу покажет, не съедено ли что-то системой заранее.

nproc --all               # сколько логических ядер видит система
lscpu | grep -E 'Model name|Socket|Core|Thread'
cat /proc/cpuinfo | grep MHz | head -4   # текущая частота ядер

Если сервер — виртуальная машина, отдельно стоит проверить steal time: долю такта, которую гипервизор забирает в пользу соседей по хосту. Это прямой индикатор, что «ваши» ядра не полностью ваши.

vmstat 1 5
# колонка st — steal time в процентах, в норме близко к 0
mpstat -P ALL 1 3

Для памяти интересны не только total и free, но и что уже занято под кэш и буферы (это не проблема — Linux агрессивно кэширует страницы, и это освобождаемая память), а также — есть ли своп и активно ли он используется прямо сейчас:

free -h
cat /proc/meminfo | grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree'
vmstat 1 5   # колонки si/so — своп-ин/своп-аут в реальном времени

Ключевая метрика для планирования — не MemTotal, а MemAvailable: это оценка ядра, сколько памяти реально можно выделить новому процессу без ухода в своп, с учётом того, что часть кэша вытеснится. Если MemAvailable заметно меньше MemTotal уже в покое — на сервере что-то держит память резидентно, и это стоит понять до того, как вы начнёте считать запас под новую нагрузку.

Отдельно нагрузочный тест CPU для вечерней карты обычно избыточен: достаточно знать номинальное число ядер, частоту и текущий steal time. Если нужен именно предел под конкретный тип нагрузки (шифрование, TLS-рукопожатия, кодирование видео), это отдельная методика под конкретную задачу, и её стоит проводить прицельно, а не как часть общей вечерней карты.

Диск и IOPS: честная методика в двух прогонах

Диск — самая долгая часть вечера и чаще всего самое узкое место у баз данных. Правильная методика замера IOPS и пропускной способности диска — отдельная большая тема с фактором конфигурации fio (глубина очереди, размер блока, паттерн доступа), которую мы подробно разбираем в статье про честный замер диска утилитой fio. Для вечерней карты пределов достаточно двух прогонов, которые дают репрезентативную пару чисел, а не абстрактный максимум:

# случайное чтение мелкими блоками — типичный паттерн для СУБД
fio --name=randread --filename=/data/testfile --size=2G \
    --rw=randread --bs=4k --iodepth=32 --numjobs=4 \
    --runtime=60 --time_based --direct=1 --group_reporting

# последовательная запись — типичный паттерн для бэкапов и WAL
fio --name=seqwrite --filename=/data/testfile --size=2G \
    --rw=write --bs=1M --iodepth=8 --numjobs=1 \
    --runtime=60 --time_based --direct=1 --group_reporting

Флаг --direct=1 обязателен — без него тест меряет скорость страничного кэша ОС, а не диска. Результат смотрите по двум полям: iops и lat (задержка). Именно задержка на плече говорит о реальном пределе раньше, чем IOPS начнёт видимо падать — если p99 задержки резко растёт при увеличении iodepth, вы нащупали потолок очереди диска.

Параллельно, во время фонового прогона fio, откройте второй терминал и смотрите загрузку устройства в реальном времени:

iostat -x 1 10
# колонка %util близка к 100 — диск действительно насыщен
# await — средняя задержка запроса в миллисекундах

Если %util уже под 100%, а IOPS не растёт даже при увеличении iodepth — это и есть практический потолок конкретного диска в конкретной конфигурации. Что означает сама цифра IOPS и почему заявленная в спецификациях цифра почти никогда не достижима на практике, разобрано отдельно в статье что такое IOPS на самом деле — если результат вечернего теста заметно ниже ожиданий, вероятная причина там.

Сеть, файловые дескрипторы и соединения к базе

Сеть. Для вечерней карты достаточно двух чисел: пропускной способности до внешней точки и задержки. Если под рукой есть второй сервер (например, второй арендованный узел или домашний канал с фиксированной скоростью), используйте iperf3:

# на одной стороне (сервер)
iperf3 -s

# на другой стороне (клиент)
iperf3 -c <ip-сервера> -t 20 -P 4

Флаг -P 4 запускает четыре параллельных потока — одиночный поток TCP часто не выбирает весь номинальный канал из-за особенностей TCP slow start и размера окна. Если второго сервера под рукой нет, ограничьтесь простым ping до нескольких внешних точек для оценки задержки и curl -o /dev/null -w '%{speed_download}\n' на файл заметного размера для грубой оценки скорости скачивания.

Файловые дескрипторы. Лимит открытых файлов — частая скрытая стена, о которую разбиваются высоконагруженные сервисы: каждое TCP-соединение, каждый открытый файл лога, каждый сокет к базе — это один дескриптор. Смотрим системный и пользовательский лимиты:

cat /proc/sys/fs/file-max        # системный потолок
cat /proc/sys/fs/file-nr         # текущее использование (первое число)
ulimit -n                        # мягкий лимит текущей сессии/процесса
cat /proc/<PID>/limits | grep 'Max open files'   # лимит конкретного процесса

Практический нюанс: лимит, установленный в /etc/security/limits.conf, применяется не всегда — для процессов, запущенных через systemd, действует LimitNOFILE в unit-файле или в /etc/systemd/system.conf, и он может отличаться от того, что видит интерактивный шелл. Подробная методика настройки и типичные грабли с ulimit разобраны в статье про настройку лимитов открытых файлов — стоит свериться с ней, если процесс падает с ошибкой Too many open files при формально «большом» лимите.

Соединения к базе данных. Здесь важно различать два числа: лимит, установленный в конфигурации СУБД, и практический потолок, после которого начинается деградация (не отказ, а именно замедление из-за конкуренции за ресурсы). Для PostgreSQL:

psql -c "SHOW max_connections;"
psql -c "SELECT count(*) FROM pg_stat_activity;"   # сколько занято сейчас

Для MySQL/MariaDB аналогично:

mysql -e "SHOW VARIABLES LIKE 'max_connections';"
mysql -e "SHOW STATUS LIKE 'Threads_connected';"

Формальный max_connections почти никогда не совпадает с практическим потолком — обычно деградация по задержке начинается заметно раньше формального лимита, потому что каждое соединение — это отдельный процесс или поток с собственным потреблением памяти, и рост их числа увеличивает конкуренцию за буферный пул и CPU. Методика поиска именно практического потолка (не формального лимита, а точки начала деградации) для PostgreSQL разобрана в статье сколько соединений к PostgreSQL до деградации — если вы отвечаете за высоконагруженную базу, стоит прогнать этот тест отдельно, а не полагаться на одну цифру max_connections.

Сводная таблица результатов

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

Конкретные значения в столбцах «Текущее» и «Потолок» — ваши, здесь намеренно оставлены как X и Y: они зависят от модели диска, версии ядра, конфигурации СУБД и от того, виртуальная это машина или выделенный сервер, и любая единая цифра в статье была бы недостоверной. Смысл таблицы не в абсолютных числах, а в том, что она превращает шесть разных замеров в одну точку сравнения — с прошлым замером, с соседним сервером, с требованиями конкретной нагрузки.

Практический совет по ведению: храните таблицу в системе контроля версий рядом с конфигами сервера (даже простой git-репозиторий с одним markdown-файлом подойдёт) — тогда diff между замерами покажет, что изменилось после апгрейда железа, обновления ядра или смены конфигурации СУБД, а не придётся вспоминать «а было ли так раньше».

Частые вопросы