Что будешь проверять при лагах сервера, если дело не в процессоре и не в нагрузке

При лагах сервера, когда явно низкая загрузка CPU и нет признаков перегрузки, я начну с комплексной диагностики по методологии "от общего к частному", анализируя ресурсы, ввод-вывод, сеть и системное ПО. Вот мой поэтапный план проверки.

🧠 1. Анализ потребления памяти и подкачки

Лаги часто вызваны не CPU, а нехваткой оперативной памяти, что приводит к активной работе подсистемы swapping (обмен с диском). Это "тихий убийца" производительности.

Проверяемые метрики и команды

• Общая картина по памяти и свопу:

  free -h
  cat /proc/meminfo | grep -E "(MemFree|SwapCached|SwapTotal|SwapFree)"
  

• Динамический мониторинг в реальном времени для отслеживания трендов:

  vmstat 2 10  # каждые 2 секунды, 10 раз. Ключевые колонки: `si` (swap in), `so` (swap out), `free`, `buff`, `cache`.
  sar -r 2 10  # более детальная статистика по памяти.
  

• Поиск процессов, активно использующих память и потенциально вызывающих OOM (Out-Of-Memory) ситуации:

  ps aux --sort=-%mem | head -20
  

Вывод: Если si и so постоянно больше нуля, особенно so — система активно "свопится". Это требует немедленного вмешательства: увеличение RAM, настройка vm.swappiness или поиск и устранение утечки памяти.

💾 2. Диагностика проблем ввода-вывода (I/O)

Медленные диски (дисковые очереди, высокая задержка) — классическая причина "лаганий", когда процессор простаивает в ожидании данных с диска.

Проверяемые метрики и команды

• Загрузка дисковых подсистем:

  iostat -x 2 5  # Ключевые колонки: `%util` (загрузка), `await` (среднее время ожидания I/O, мс), `svctm` (время обслуживания). `await` > 20-30 мс — сигнал.
  iotop -o     # Показывает процессы, активно работающие с диском, в реальном времени.
  

• Статистика использования файловых дескрипторов. Их исчерпание может приводить к странным ошибкам и зависаниям:

  lsof | wc -l  # Общее количество открытых файлов.
  cat /proc/sys/fs/file-nr  # Показывает: выделено, использовано, максимум.
  ulimit -n     # Проверка лимитов для текущей сессии.
  

Вывод: Высокий await и %util указывают на перегруженный/медленный диск или проблему с RAID. iotop поможет найти виновника.

🌐 3. Анализ сетевых задержек и проблем сети

Сетевые латентность (latency) и потери пакетов (packet loss) могут восприниматься как лаги сервера, особенно для сетевых приложений (БД, бэкенды).

Проверяемые метрики и команды

• Базовые сетевые метрики:

  netstat -i    # Статистика по интерфейсам, колонки ошибок.
  ip -s link    # Более детальная статистика.
  

• Отслеживание сетевых соединений и их состояния. Переполнение очередей или большое количество соединений в "нестандартных" состояниях (например, TIME_WAIT) может быть проблемой:

  ss -s         # Краткая сводка по сокетам.
  ss -tan state time-wait | wc -l  # Подсчет соединений в состоянии TIME_WAIT.
  

• Измерение сетевой задержки и потерь до критических точек (шлюз, соседний сервис):

  ping -c 20 <IP_шлюза_или_сервиса>
  mtr <IP_цели>  # Комбинирует traceroute и ping, лучше для диагностики.
  

• Проверка настроек сетевых очередей и возможного их переполнения:

  netstat -s | grep -E "(segments retransmited|packet receive errors)"
  

Вывод: Потери пакетов, высокая ретрансмиссия или заполнение сетевых очередей вызовут лаги в сетевых операциях.

🛠️ 4. Проверка системных ограничений и конфигурации

• Исчерпание лимитов процессов или потоков:

  ps -eLf | wc -l  # Подсчет общего количества потоков (LWP).
  cat /proc/sys/kernel/pid_max
  cat /proc/sys/kernel/threads-max
  ulimit -u       # Максимальное число процессов для пользователя.
  

• Анализ планировщика задач и приоритетов. Некорректные nice значения или проблемы с cgroups могут приводить к "голоданию" процессов.

• Проверка корректности времени (NTP). Рассинхронизация времени в распределенных системах может вызвать неочевидные лаги, проблемы с аутентификацией и логированием.

  timedatectl status
  ntpq -p
  

📊 5. Глубокий анализ с помощью профилирования и трассировки

Если все вышеперечисленное не выявило причину, перехожу к низкоуровневым инструментам.

• strace/perf для анализа системных вызовов:

  # Куда процесс тратит реальное время? Много ли вызовов read/write/poll?
  strace -c -p <PID>  # Собирает статистику по syscalls для процесса.
  perf top            # Показывает, какие функции ядра/пользователя потребляют CPU.
  

• Анализ логов ядра (dmesg) и системных логов. Поиск критических ошибок (OOM-killer, hardware issues, файловые системы):

  dmesg -T | tail -50
  journalctl --since "10 minutes ago" -p err  # В системах с systemd.
  

• Профилирование работы сборщика мусора (Garbage Collector), если сервер работает на JVM (Java). Длительные паузы GC ("stop-the-world") — частая причина лагов при низкой загрузке CPU.

  jstat -gc <vmid> 2s  # Для Java-процессов.
  

Общий алгоритм действия:

1. Сбор базовых метрик (vmstat, iostat, free).
2. Идентификация узкого места (Memory? I/O? Network?).
3. Поиск конкретного процесса-виновника (iotop, ps, ss).
4. Углубленная диагностика процесса (strace, анализ его логов, GC-логов).
5. Анализ внешних факторов (сеть, соседние сервисы, обновления, бэкапы).

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