Мониторинг Linux-сервера: загрузка процессора, памяти и диска

Когда сервер начинает тупить, а сайт открывается с задержкой в несколько секунд, первое, что хочется сделать — перезагрузить. Но это плохая привычка. Перезагрузка маскирует проблему, а не решает её. Гораздо полезнее за две минуты понять, что именно стало узким местом: процессор, память или диск. Для этого не нужны сложные системы мониторинга — достаточно трёх-четырёх команд, которые есть в любом дистрибутиве Linux.

Я сам не раз попадал в ситуацию, когда сервер с виду работал, но клиенты жаловались на тормоза. Открываешь top — а там процессор на 90% загружен какой-нибудь кривой задачей cron, которая пошла в разнос. Или смотришь free -h — памяти вроде много, а available почти на нуле, и система уже активно свопится на диск. Без понимания этих метрик можно часами гадать, в чём дело.

Зачем вообще следить за ресурсами сервера

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

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

Классическая ошибка новичка: увидел высокий load average и сразу решил, что процессор не справляется. А на деле сервер может простаивать, пока какой-нибудь скрипт ждёт ответа от медленного диска или сетевого хранилища. Именно поэтому в Linux нагрузка системы считается не только по активным процессам, но и по тем, что находятся в состоянии uninterruptible sleep — они застряли в ожидании I/O и не могут быть прерваны.

Какие метрики нужно смотреть в первую очередь

1. Загрузка процессора

CPU — это вычислительный ресурс в чистом виде. Когда процессор загружен, он либо выполняет код приложения, либо обрабатывает системные вызовы ядра. Но есть нюанс: в показателях загрузки процессора есть отдельная графа %wa — время ожидания ввода-вывода. Если она высокая, процессор на самом деле не столько считает, сколько ждёт, пока диск или сеть отдадут данные. Это принципиально важно для диагностики: проблема может быть не в CPU, а в дисковой подсистеме.

Также стоит обращать внимание на распределение нагрузки по ядрам. Бывает, что общий процент загрузки небольшой, но одно ядро забито под 100% однопоточным процессом, и сервер при этом тормозит. Такое часто случается с Python-скриптами или старыми версиями PHP, которые не умеют работать в несколько потоков.

2. Память

С памятью в Linux всё не так очевидно, как кажется. Если вы посмотрите на вывод free -h и увидите, что свободной памяти почти нет — не паникуйте раньше времени. Linux агрессивно использует оперативную память под файловый кэш, потому что держать данные в RAM быстрее, чем читать их с диска. Это нормальное и правильное поведение.

Ключевой показатель, на который нужно ориентироваться — available. Он показывает, сколько памяти реально доступно для запуска новых процессов без вытеснения чего-то важного в swap. Если available стабильно держится выше 10-15% от общего объёма RAM, скорее всего, с памятью всё в порядке. Если же он уходит в район нескольких мегабайт — пора разбираться, кто съедает ресурсы.

3. Диск

Дисковая подсистема — самое коварное узкое место. Процессор может быть загружен на 20%, память свободна, а сервер всё равно тормозит, потому что диск не справляется с потоком операций. Особенно это заметно на виртуальных серверах с медленным хранилищем или на старых HDD, где скорость случайного чтения-записи измеряется десятками операций в секунду.

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

Базовые команды для быстрой проверки

За годы практики у меня сложился минимальный набор из четырёх команд, которые позволяют за минуту оценить состояние сервера. Не нужно запоминать десятки утилит — начните с этих, а остальное придёт с опытом.

Рекомендуемый минимальный набор для ежедневной проверки — top или htop, free -h и df -h. Этого достаточно, чтобы заметить аномалию и понять, куда копать дальше.

Как читать нагрузку процессора

top

top — это первая команда, которую я набираю, когда сервер начинает вести себя странно. Она показывает живую картину происходящего: какие процессы активны прямо сейчас, сколько процессорного времени они отъедают, какой процент уходит на системные вызовы, а какой — на ожидание диска.

В верхней части вывода есть строка с разбивкой процессорного времени:

• %us — время, потраченное на выполнение пользовательского кода. Это ваши приложения, скрипты, базы данных.
• %sy — время, которое ядро потратило на системные вызовы. Высокое значение здесь может указывать на то, что какой-то процесс активно дёргает систему.
• %wa — время ожидания ввода-вывода. Если эта цифра стабильно выше 5-10%, диск не справляется с нагрузкой.
• %id — простой процессора. Чем выше, тем лучше.

Из практики: если вы видите %wa на уровне 20-30%, а процессор при этом загружен слабо — не спешите наращивать CPU. Проблема почти наверняка в дисковой подсистеме или сетевом хранилище. Я однажды потратил полдня, пытаясь оптимизировать запросы к базе данных, а оказалось, что виртуальный диск VPS был забит операциями от соседей по хосту.

htop

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

На сервере с веб-нагрузкой htop особенно полезен: вы сразу видите, сколько процессов PHP или workers вашего веб-сервера активны, кто из них потребляет больше всего ресурсов, не ушёл ли какой-нибудь скрипт в бесконечный цикл. Цветовая индикация помогает мгновенно заметить процесс, который вышел за разумные пределы.

load average

Load average — это, пожалуй, самый недопонимаемый показатель в Linux. Многие новички думают, что это проценты загрузки процессора, и пугаются, когда видят значения 2.0 или 3.0. На самом деле load average показывает среднее количество процессов, которые находятся в состоянии выполнения или ожидания за последние 1, 5 и 15 минут.

Простой ориентир для интерпретации:

• Если load average меньше количества ядер — система справляется с нагрузкой, процессы не скапливаются в очереди.
• Если load average равен количеству ядер — система работает на пределе, но пока без деградации.
• Если load average заметно превышает количество ядер — процессы начинают ждать своей очереди на выполнение, пора разбираться.

Особый случай: высокий load average при низкой загрузке процессора. Это классический признак проблем с диском или сетевым хранилищем. Процессы висят в состоянии uninterruptible sleep, не потребляют CPU, но учитываются в load average. Я не раз сталкивался с этим на серверах, где использовались сетевые файловые системы — малейшая задержка в сети, и load average взлетал до небес.

Как проверять память

free -h

Команда free -h — мой основной инструмент для оценки состояния памяти. Ключ -h включает человекочитаемый формат: мегабайты и гигабайты вместо длинных столбцов цифр в килобайтах.

Вывод команды содержит несколько полей, но самое важное — available. Именно оно показывает, сколько памяти система может выделить под новые процессы без свопинга. Поле free часто выглядит пугающе маленьким, но это нормально: Linux держит в памяти файловый кэш и освобождает его при необходимости. Если available в порядке, а free почти на нуле — система работает как задумано.

Что считается тревожным

За годы практики я выработал для себя несколько триггеров, при которых нужно начинать беспокоиться о памяти:

• available стабильно держится ниже 5% от общего объёма RAM. Это значит, что система балансирует на грани и любой всплеск активности может отправить её в swap.
• Swap активно используется не эпизодически, а постоянно. Если объём данных в swap растёт и не уменьшается — серверу хронически не хватает оперативной памяти.
• В логах появляются сообщения об OOM-killer — это значит, что ядро уже начало убивать процессы для освобождения памяти. Ситуация аварийная.
• Сервер начинает отвечать с большой задержкой, а диск при этом непрерывно шуршит — скорее всего, система активно свопится, и узким местом стал именно диск.

Отдельно стоит сказать про утечки памяти. Если вы замечаете, что потребление RAM каким-то процессом медленно, но неуклонно растёт — это повод проверить код или конфигурацию. Такое часто случается с самописными скриптами на Python или Node.js, где забывают закрывать соединения или освобождать ресурсы.

Как проверять диск

df -h

df -h — это базовая проверка свободного места на файловых системах. Команда показывает все смонтированные разделы, их размер, занятое и свободное пространство, а также точку монтирования. С ключом -T добавляется информация о типе файловой системы, что бывает полезно при диагностике.

На что я всегда обращаю внимание:

• Корневой раздел / — если он заполнится, система может перестать работать. Держите там хотя бы 10-15% свободного места.
• /var — здесь живут логи, кэши пакетных менеджеров, данные баз данных. Логи имеют свойство разрастаться незаметно, особенно если не настроена ротация.
• Отдельные тома под базы данных — заполнение такого раздела может привести к остановке СУБД и отказу в обслуживании.
• Точки монтирования для бэкапов — если бэкап-раздел заполнился, новые копии перестанут создаваться, и вы узнаете об этом в самый неподходящий момент.

Почему мало просто смотреть на свободное место

Сервер может иметь сотни гигабайт свободного места на диске и при этом тормозить так, будто он работает с дискеты. Дело в том, что df показывает только объём, но ничего не говорит о скорости операций ввода-вывода.

Если диск медленный или перегруженный, процессы будут накапливаться в очереди на чтение-запись, а вы увидите это как высокий %wa в top и повышенный load average. Такое часто бывает на дешёвых VPS, где дисковая подсистема виртуализирована и ресурсы делятся между множеством клиентов. В этом случае даже 90% свободного места не спасут — проблема в скорости, а не в объёме.

Практический чек-лист для диагностики

Когда сервер начинает тормозить, я прохожу по этому списку — он занимает буквально пару минут и в 90% случаев позволяет локализовать проблему:

• Проверить общий load average через uptime или top. Сравнить с количеством ядер и обычными значениями для этого сервера в это время суток.
• Посмотреть, нет ли процесса, который забрал CPU в top или htop. Часто виновник сразу виден в верхних строчках.
• Проверить free -h и убедиться, что available не близок к нулю. Оценить использование swap.
• Проверить df -h по всем важным разделам. Особое внимание — корню и /var.
• Если сервер тормозит, но CPU и память в порядке — обратить внимание на %wa в top. Высокий процент ожидания ввода-вывода указывает на дисковую проблему.
• Сравнить текущую нагрузку с обычным поведением сервера в рабочие часы. Иногда проблема не в абсолютных значениях, а в отклонении от нормы.

Типовые ошибки новичков

1. Считать free память «плохой»

В Linux это нормально, когда поле free показывает маленькие значения. Система использует незанятую память под файловый кэш и при необходимости освобождает её за миллисекунды. Ориентироваться нужно на available, а не на free. Я не раз видел, как начинающие администраторы начинали паниковать и убивать процессы при виде free: 200M на сервере с 16 гигабайтами RAM, хотя available показывал 12 гигабайт.

2. Путать load average с процентом CPU

Load average и загрузка процессора — это разные метрики, которые дополняют друг друга, но не взаимозаменяемы. Load average показывает длину очереди задач, а процент CPU — насколько занят процессор в данный момент. Можно иметь load average 10 при загрузке CPU 20% — это будет означать, что процессы стоят в очереди не из-за процессора, а из-за ожидания диска или сети.

3. Смотреть только на один раздел

Заполниться может не только корень, но и /var, где лежат логи, кэши пакетного менеджера и временные файлы. Или /tmp, куда какой-нибудь скрипт начал писать гигабайты отладочной информации. Проверяйте все разделы, а не только /.

4. Игнорировать swap

Если swap используется постоянно и в больших объёмах — это симптом, а не причина. Серверу не хватает оперативной памяти, и он вынужден сбрасывать данные на диск, который на порядки медленнее RAM. Эпизодическое использование swap допустимо, но если оно превращается в постоянный процесс — нужно либо добавлять память, либо искать утечку.

5. Искать проблему только в CPU

Процессор — самая очевидная цель для диагностики, но далеко не всегда узкое место находится именно там. Дисковая подсистема, нехватка памяти, сетевые задержки — всё это может тормозить сервер сильнее, чем загруженный под 100% процессор. Всегда проверяйте полную картину, а не один показатель.

Когда нужен уже не ручной мониторинг, а система наблюдения

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

Если сервер один и он учебный или тестовый — ручного мониторинга вполне достаточно. Зашли раз в день, проверили top, free, df — и живёте спокойно. Но как только серверов становится два и больше, или на них крутится что-то важное для бизнеса, пора подключать системы сбора метрик и алертов.

Для продакшена я рекомендую смотреть в сторону связки Prometheus + Grafana или Zabbix. Они собирают историю по CPU, памяти, диску и десяткам других метрик, позволяют строить графики и, главное, настраивать уведомления по порогам. Вы получите сообщение в мессенджер или на почту до того, как проблема станет заметна пользователям. Это совершенно другой уровень контроля по сравнению с ручными проверками.

Пошаговая схема проверки проблемного сервера

Когда мне звонят или пишут с сообщением «сервер лежит» или «всё тормозит», я действую по одному и тому же алгоритму. Он не раз спасал от поспешных выводов и помогал быстро находить реальную причину:

1. Откройте top или htop. Первый взгляд на общую картину: загрузка процессора, память, список процессов.
2. Посмотрите, не упирается ли система в один процесс. Если какой-то процесс забрал 80-100% CPU — вы нашли виновника.
3. Оцените load average. Сравните с количеством ядер и с обычными значениями для этого времени суток.
4. Проверьте free -h. Если available на нуле, а swap забит — проблема в памяти.
5. Проверьте df -h. Убедитесь, что ни один раздел не заполнен под завязку.
6. Если всё выглядит нормально, но сервер тормозит — смотрите на %wa в top и дисковую активность. Скорее всего, проблема в дисковой подсистеме.
7. Сравните текущие значения с обычной нагрузкой в это же время суток. Иногда аномалия видна только в динамике.

Что запомнить

Мониторинг Linux-сервера — это не магия и не искусство, а навык, который нарабатывается за несколько недель практики. Начните с трёх вещей: процессор, память, диск. Для быстрой диагностики держите под рукой top или htop, free -h и df -h. Для понимания общей картины смотрите на load average и процент ожидания ввода-вывода.

Если научиться правильно читать эти показатели, большинство проблем можно найти за пару минут. А дальше — уже дело техники: добавить памяти, расширить диск, оптимизировать запрос или перенести нагрузку на другое время.

FAQ

Какой минимальный набор команд нужен для мониторинга Linux-сервера?

top или htop, free -h, df -h и uptime. Этого достаточно для ежедневной проверки и первичной диагностики проблем.

Почему сервер может тормозить при низкой загрузке CPU?

Частая причина — ожидание дисковых операций. Процессы не потребляют процессорное время, но висят в очереди на чтение или запись. В Linux такие задержки отражаются в load average и в показателе %wa в top.

Что важнее смотреть в памяти — free или available?

Для практики важнее available. Он показывает, сколько памяти реально можно использовать без того, чтобы система начала вытеснять данные в swap. free часто выглядит маленьким из-за файлового кэша, и это нормально.

Как понять, что диск стал узким местом?

Если растёт %wa в top, сервер периодически «зависает» на операциях с файлами, а load average высокий при не очень загруженном процессоре — проблема почти наверняка в диске или сетевом хранилище.

Нужно ли ставить отдельную систему мониторинга на один сервер?

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