Введение: «Выключить и включить» — это не метод

«Сайт открывается медленно», «База данных тупит», «SSH лагает». Это самые частые жалобы.

Реакция новичка — перезагрузка. Это «лечение симптомов». Проблема исчезнет на час, а потом вернется, потому что вы не нашли причину. К тому же, в Enterprise-среде перезагрузка — это простой бизнеса и потеря денег.

«Архитектор будущего» действует как врач-диагност. У него есть чек-лист показателей. Он не гадает, он измеряет.

В этом гайде мы разберем метод USE (Utilization, Saturation, Errors) и 5 инструментов, которые покажут вам правду за 60 секунд.

Шаг 1. Общая картина: Load Average

Первое, что мы набираем — uptime или top.

Bash

$ uptime
 14:30:05 up 10 days,  4:15,  1 user,  load average: 0.50, 10.05, 25.30

Смотрим на Load Average (средняя загрузка за 1, 5 и 15 минут).

Что это? Количество процессов, которые либо используют процессор, либо ждут очереди к нему (или к диску!).
Как читать: Если у вас 4 ядра, то LA = 4.0 — это 100% загрузка.
- LA < количества ядер: Всё ок.
- LA > количества ядер: Очередь растет, сервер «захлебывается».

Архитекторский взгляд: Если LA высокий (например, 25.30 при 4 ядрах), не спешите винить процессор. Часто проблема в диске.

Шаг 2. Процессор или Диск? (top / htop)

Запускаем top. Смотрим не на список процессов, а на «шапку» — строку %Cpu(s).

Plaintext

%Cpu(s): 10.5 us,  5.2 sy,  0.0 ni, 80.0 id,  4.1 wa,  0.0 hi,  0.2 si

Разшифровка магии:

us (user): Полезная нагрузка (ваши программы: PHP, MySQL, Java). Если здесь 100% — ищите процесс-виновник ниже в списке.
sy (system): Ядро системы. Если высоко — проблема в драйверах или огромном количестве системных вызовов.
wa (iowait): САМОЕ ВАЖНОЕ. Это время, которое процессор простаивает, ожидая ответа от диска.

Диагноз:

Высокий us? -> Процессор занят вычислениями (майнер? зацикленный скрипт?).
Высокий wa? -> Проблема не в процессоре! Проблема в диске. Диск не успевает записывать/читать.

Шаг 3. Оперативная память: «Linux съел мою память?»

Смотрим free -m.

Bash

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7976        2000         500          10        5476        5800
Swap:          2047           0        2047

Новички паникуют: «О боже, free всего 500 МБ!».

Архитектор спокоен.

used: Реально занятая программами память.
buff/cache: Linux не дурак. Свободную память он использует для кэширования файлов с диска, чтобы система летала. Эта память освобождается мгновенно, если она понадобится приложениям.
available: Вот ваша реальная свободная память. Если она близка к нулю — это проблема (OOM Killer скоро придет убивать процессы).

Тревожный сигнал: Если Swap используется (used > 0) и постоянно растет. Это значит, что RAM не хватает, и система сбрасывает данные на медленный диск. Это убивает производительность (привет, высокий iowait).

Шаг 4. Кто убивает диск? (iotop)

Если на Шаге 2 вы увидели высокий wa (iowait), вам нужно знать имя виновника. Обычный top этого не покажет.

Вам нужен iotop (установите его: apt install iotop / yum install iotop).

Запускаем: sudo iotop -oPa

-o: Показать только те процессы, которые реально грузят диск.
-P: Показать процессы, а не потоки.
-a: Накапливать статистику (показывает, кто записал больше всего данных с момента запуска утилиты).

Вы сразу увидите: «Ага, это mysqld делает тяжелый SELECT и вычитывает гигабайты» или «Это rsync делает бэкап и положил диск».

Шаг 5. Сеть и «бутылочное горлышко» (iftop / ss)

Если CPU, RAM и Диск в порядке, но «всё тормозит», возможно, забит сетевой канал.

iftop (аналог top для сети): Показывает в реальном времени, кто и с кем общается и на какой скорости.
- Пример: Вы увидите, что сервер отдает бэкап на скорости 1 Гбит/с, забивая весь канал, поэтому сайт не открывается.
ss -s: Быстрая сводка по сокетам.
- Если вы видите тысячи соединений в статусе TIME-WAIT или SYN-RECV, возможно, вас DDoS-ят или у вас неправильно настроен веб-сервер (Nginx/Apache).

Вывод: Алгоритм Архитектора

В следующий раз, когда вам скажут «Сервер тормозит», не перезагружайте его. Следуйте алгоритму:

uptime: Смотрим Load Average. Если высокий — копаем дальше.
top: Смотрим %Cpu.
- Много us? -> Ищем «жрущий» процесс.
- Много wa? -> Проблема в диске.
iotop: (Если проблема в диске) Находим процесс, убивающий диск.
free -m: Проверяем available и swap. Не ушли ли мы в своп?
iftop: Проверяем, не забит ли канал.

За 60 секунд вы найдете причину. И вместо слепой перезагрузки вы сможете принять точечное, «хирургическое» решение: оптимизировать запрос в БД, перенести бэкап на ночь или добавить памяти.

Это и есть путь от «эникейщика» к системному архитектору.

Теги:

#linux #troubleshooting #performance #sysadmin #devops #top #diagnostics #server

Хотите стать архитектором будущего, а не просто админом? Эта статья — лишь верхушка айсберга. В нашем Telegram-канале «Admin Future» мы каждый день публикуем системные гайды, готовые скрипты, AI-лайфхаки и чеклисты, которые не найти в Google. Мы не просто постим команды — мы строим библиотеку знаний для тех, кто хочет расти от админа до архитектора. Подписывайтесь и становитесь экспертом: Admin Future

Сервер «тормозит»: Пошаговый гайд по диагностике производительности Linux (без перезагрузки)