Как понять сисадмину, что сервер работает на пределе

Для администратора формулировка “сервер работает на пределе” означает не просто высокий процент загрузки ресурсов, а состояние, при котором система теряет запас по производительности, растёт latency, ухудшается предсказуемость отклика и любое дополнительное воздействие — всплеск трафика, backup, compaction, пересборка индексов, cron-задачи — может вызвать деградацию сервиса или отказ.

Ключевой момент: сервер редко “упирается” равномерно во всё сразу. Почти всегда есть конкретное узкое место:

• CPU;
• RAM;
• дисковая подсистема;
• сеть;
• блокировки и конкуренция за ресурсы;
• лимиты ОС;
• гипервизор или внешняя инфраструктура;
• само приложение или СУБД.

Ниже — технические признаки, на которые стоит смотреть в первую очередь.

1. CPU: важно не только %usage, но и run queue, steal, iowait

Высокая загрузка CPU сама по себе ещё не означает аварию. Для sysadmin важнее контекст:

• сколько времени CPU находится в user, system, iowait, steal;
• есть ли очередь на исполнение;
• сколько runnable tasks ждут CPU;
• не упирается ли процесс в single-core bottleneck;
• не маскируется ли проблема диска под высокую системную нагрузку.

На что смотреть

• load average в сравнении с количеством vCPU;
• %idle, %user, %system, %iowait, %steal;
• длину run queue;
• рост context switches;
• softirq / irq нагрузку;
• CPU throttling;
• частоты CPU и c-state/p-state поведение.

Тревожные признаки

• load average стабильно выше числа доступных vCPU;
• низкий %idle в течение длительного времени;
• высокий %steal на виртуальной машине;
• рост %iowait, когда кажется, что “процессор загружен”, но реально система ждёт диск;
• один или несколько hot threads упираются в одно ядро, тогда общая загрузка CPU может выглядеть “нормально”.

Полезные инструменты

• top, htop
• mpstat -P ALL 1
• vmstat 1
• sar -u 1 10
• pidstat -u -t 1
• perf top
• perf stat
• dmesg, journalctl

Если у вас 8 vCPU и load average держится на уровне 12–20, при этом растёт latency приложений и время выполнения задач — сервер уже в зоне риска.
Если на VM %steal регулярно выше 5–10%, проблема может быть не в вашем приложении, а в noisy neighbor или дефиците CPU на хосте.

2. RAM: важен не объём занятой памяти, а reclaim pressure, swap и OOM-risk

На Linux “свободная память” как метрика сама по себе малоинформативна. Ядро использует память под page cache и slab, и это нормально. Критично другое:

• есть ли давление на reclaim;
• начинается ли swap activity;
• растут ли major page faults;
• приближается ли система к OOM;
• не утекла ли память в userspace или kernel space.

На что смотреть

• MemAvailable, а не только MemFree;
• swap in / swap out;
• major/minor page faults;
• slab usage;
• page cache;
• committed memory;
• OOM events;
• PSI по памяти (/proc/pressure/memory);
• reclaim activity (kswapd, direct reclaim).

Тревожные признаки

• swap начинает использоваться не эпизодически, а регулярно;
• наблюдается si/so в vmstat;
• растёт latency одновременно с reclaim;
• kswapd активно работает даже на обычной нагрузке;
• процессы получают OOM kill;
• база данных и файловый кэш начинают конкурировать за память;
• контейнеры упираются в memory limits и ловят eviction/restart.

Инструменты

• free -h
• vmstat 1
• sar -r 1 10
• cat /proc/meminfo
• slabtop
• smem
• ps aux --sort=-%mem
• dmesg | grep -i oom
• journalctl -k
• cat /proc/pressure/memory

Если память “почти заполнена”, но swap не используется, reclaim спокоен, latency не растёт — это может быть нормой.
Если даже небольшой всплеск нагрузки вызывает direct reclaim, swap I/O и рост времени отклика — сервер уже работает без запаса.

3. Дисковая подсистема: упираются не в гигабайты, а в latency, IOPS и queue depth

Один из самых частых сценариев деградации — диск становится узким местом, а внешне это выглядит как “тормозит всё”.

На что смотреть

• await, svctm, %util;
• queue depth;
• read/write IOPS;
• throughput;
• latency по устройствам;
• fsync latency;
• inode exhaustion;
• free space;
• состояние RAID / NVMe / SAN;
• ошибки файловой системы и блока.

Тревожные признаки

• высокий await даже при умеренном потоке операций;
• %util устройства близок к 100% длительное время;
• растёт очередь запросов;
• запись блокируется из-за flush/fsync;
• БД показывает резкий рост query latency без роста CPU;
• backup, logrotate, compaction, vacuum или indexing “кладут” прод;
• мало свободного места на разделе, особенно для БД, логов, /var, /tmp.

Инструменты

• iostat -xz 1
• iotop
• pidstat -d 1
• df -h
• df -i
• lsblk
• smartctl
• nvme smart-log
• dmesg
• fio для controlled testing вне production peak

%util=100% не всегда значит катастрофу, особенно на быстрых NVMe. Гораздо важнее фактическая latency.
Если await вырос с 2–5 ms до 30–100+ ms на рабочей нагрузке, приложение и БД почти наверняка уже чувствуют предел.

4. Сеть: saturation, drops, retransmits, queueing

Проблема сети часто недооценивается. Сервис может выглядеть “живым”, но пользователи видят высокое время ответа из-за потерь, ретрансмитов, переполнения буферов или saturation канала.

На что смотреть

• throughput по интерфейсам;
• drops, errors, overruns;
• retransmits;
• TCP backlog;
• SYN queue;
• socket states;
• connection tracking;
• packet loss;
• RTT/jitter;
• saturation uplink/downlink.

Тревожные признаки

• рост retransmits;
• переполнение listen queue;
• всплески TIME_WAIT, SYN_RECV, CLOSE_WAIT;
• исчерпание ephemeral ports;
• превышение conntrack limits;
• drops на интерфейсе или балансировщике;
• сетевой throughput близок к физическому/виртуальному лимиту.

Инструменты

• ss -s
• ss -lnt
• netstat -s
• sar -n DEV 1
• sar -n TCP,ETCP 1
• ip -s link
• ethtool -S <iface>
• conntrack -S
• tcpdump
• mtr, ping

Если приложение “случайно” начинает отвечать медленно, а CPU и диск в норме, проверьте retransmits, backlog и состояние сокетов.
Для high-concurrency сервисов проблема часто не в сырой пропускной способности, а в очередях соединений и лимитах ядра.

5. Load average: полезен только если понимать, что он считает

load average — это не “процент загрузки CPU”. Это среднее число задач в runnable и uninterruptible state. Поэтому высокий load может означать:

• реальную нехватку CPU;
• ожидание диска;
• зависание на I/O;
• проблемы NFS / block storage;
• lock contention.

Высокий load при высоком %iowait — чаще про диск или сеть хранения, чем про CPU.
Высокий load при нормальном %idle и большом числе задач в D state — это почти всегда сигнал смотреть в сторону I/O.

6. Процессы и планировщик: saturation, contention, throttling

Сервер может выглядеть “вроде бы живым”, но деградировать из-за конкуренции процессов.

На что смотреть

• количество runnable tasks;
• процессы в D state;
• context switches;
• voluntary/non-voluntary switches;
• cgroup throttling;
• CPU quota exhaustion;
• scheduler latency;
• pinned threads;
• NUMA imbalance.

Инструменты

• ps -eo pid,ppid,cmd,%mem,%cpu,state --sort=-%cpu
• pidstat -w 1
• vmstat 1
• cat /sys/fs/cgroup/...
• numastat
• taskset
• chrt
• perf sched

Тревожные признаки

• контейнер регулярно упирается в cpu.cfs_quota_us;
• много процессов в D;
• высокая scheduler latency;
• потоки приложения борются за mutex/lock;
• неправильная NUMA-локальность на крупных серверах.

7. Лимиты ОС: file descriptors, processes, sockets, conntrack

Иногда сервер “на пределе” не по железу, а по лимитам.

Критичные лимиты

• ulimit -n / open files;
• ulimit -u / max user processes;
• fs.file-max;
• somaxconn;
• tcp_max_syn_backlog;
• nf_conntrack_max;
• pid_max;
• лимиты systemd unit;
• cgroup limits.

Симптомы

• Too many open files;
• отказ создавать новые соединения;
• непредсказуемые ошибки приложений;
• сервис принимает не все входящие подключения;
• странные таймауты под пиком нагрузки.

Инструменты

• ulimit -a
• sysctl -a
• cat /proc/sys/fs/file-nr
• lsof | wc -l
• systemctl show <unit>
• cat /proc/<pid>/limits

8. Приложение и БД: системные метрики без app-level telemetry дают неполную картину

Даже если CPU/RAM/диск выглядят приемлемо, сервис может уже быть на пределе на уровне приложения.

Что смотреть у приложения

• p50 / p95 / p99 latency;
• RPS/QPS;
• error rate;
• timeout rate;
• queue length;
• thread pool saturation;
• GC pauses;
• worker utilization;
• upstream dependency latency.

Что смотреть у БД

• slow queries;
• lock wait time;
• deadlocks;
• buffer/cache hit ratio;
• replication lag;
• checkpoint pressure;
• temp file growth;
• vacuum/autovacuum lag;
• connections saturation.

Типичный сценарий

CPU сервера 45–55%, памяти достаточно, но:

• p99 вырос в 5 раз;
• пул соединений к БД забит;
• запросы встают в lock wait;
• один тяжёлый SQL тормозит весь сервис.

Формально “железо ещё не на 100%”, а practically production уже на пределе.

9. Виртуализация и облако: noisy neighbor, steal time, EBS/network limits

На VM и в облаке важно отделять проблему гостевой ОС от проблемы платформы.

На что смотреть

• %steal;
• burst balance / credits;
• лимиты network/storage;
• throttling блочного устройства;
• oversubscription хоста;
• latency внешнего диска;
• балансировщик и NAT gateway limits.

Симптомы

• непредсказуемая деградация в одно и то же время;
• spikes latency без роста локальной нагрузки;
• ухудшение I/O при формально “свободном” CPU;
• исчезающие после миграции VM проблемы.

10. Журналы ядра и аппаратные ошибки

Иногда сервер “упирается” не в нагрузку, а в деградацию железа или драйверов.

Что искать

• I/O errors;
• reset контроллера;
• ext4/xfs warnings;
• OOM killer;
• NIC flaps;
• RAID degraded;
• ECC/memory errors;
• thermal throttling;
• firmware/driver issues.

Инструменты

• dmesg -T
• journalctl -k -p warning
• smartctl -a
• mdadm --detail
• vendor-specific hardware tools
• ipmitool sel list

Практические критерии: когда можно говорить, что сервер реально на пределе

Технически сервер стоит считать работающим на пределе, если выполняются один или несколько пунктов:

1. Нет эксплуатационного запаса
   Любой дополнительный фоновой job, пик трафика или failover вызывает заметную деградацию.
2. Latency растёт непропорционально нагрузке
   Небольшой прирост RPS приводит к резкому росту p95/p99.
3. Есть устойчивое saturation по одному ресурсу
   Например:
   • CPU run queue растёт;
   • постоянный memory reclaim;
   • storage latency существенно выше нормы;
   • сеть близка к saturation или растут drops/retransmits.
4. Появляются очереди и таймауты
   На входе, в thread pools, в очередях БД, в сокетах, в диске.
5. Система теряет предсказуемость
   Средние метрики ещё “терпимы”, но хвост latency уже плохой и сервис нестабилен.
6. Начинаются вторичные эффекты
   • cron-задачи не успевают;
   • backup конфликтует с прод-нагрузкой;
   • репликация отстаёт;
   • растут retries;
   • watchdog/restart начинает срабатывать чаще.

Предлагаем серверное обслуживание под ключ.