Как проверить, какие службы замедляют загрузку сервера?

Что влияет на скорость загрузки Linux VPS

Загрузка Linux-сервера состоит из нескольких этапов. Сначала запускается ядро, затем система инициализации systemd поднимает службы: сеть, SSH, cron, логирование, firewall, базы данных, веб-сервер, панели управления и другие компоненты.

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

На VPS чаще всего задержки связаны с такими причинами:

• служба долго ждёт сеть или DNS;

• ошибка в конфигурации сервиса;

• неудачный запуск базы данных или веб-сервера;

• подключение несуществующего диска или mount-точки;

• проблемы с обновлениями пакетов;

• упавшие systemd-службы после перезагрузки.

Наша задача — не гадать, а посмотреть фактическую картину загрузки.

Проверяем общее время загрузки

Начать лучше с команды systemd-analyze. Она показывает, сколько времени заняли основные этапы загрузки:

systemd-analyze

Пример вывода может выглядеть так:

Startup finished in 2.1s (kernel) + 8.4s (userspace) = 10.5s
multi-user.target reached after 8.3s in userspace.

Здесь важны две части:

• kernel — время загрузки ядра;

• userspace — время запуска служб и пользовательского окружения.

Если userspace занимает слишком много времени, обычно стоит искать медленные службы. Если долго грузится kernel, причина может быть глубже: ядро, драйверы, диски, особенности виртуализации или проблемы на стороне провайдера.

Ищем самые медленные службы

Команда systemd-analyze blame показывает службы и unit-файлы, которые дольше всего запускались при последней загрузке:

systemd-analyze blame

Чтобы вывод был короче и удобнее для анализа, можно посмотреть первые 20 строк:

systemd-analyze blame | head -20

Слева будет время, справа — название службы или unit-файла. Например:

5.831s networking.service
3.412s nginx.service
2.104s mysql.service

Но важно понимать: blame показывает длительность запуска конкретного unit, а не всегда доказывает, что именно он виноват во всей задержке. Некоторые службы запускаются параллельно, а некоторые ждут другие зависимости.

Поэтому после blame полезно посмотреть цепочку загрузки через critical-chain.

Смотрим критическую цепочку загрузки

systemd-analyze critical-chain показывает цепочку unit-файлов, которые реально влияли на достижение целевого состояния системы.

systemd-analyze critical-chain

Эта команда помогает понять не только «что запускалось долго», но и «что задерживало следующий этап загрузки».

Например, служба может запускаться 10 секунд, но не блокировать загрузку сайта или SSH. А другая служба может запускаться 3 секунды, но находиться в критической цепочке и задерживать переход системы в рабочее состояние.

Именно поэтому blame и critical-chain лучше смотреть вместе.

Проверяем упавшие службы после загрузки

Медленная загрузка иногда связана не с тем, что служба долго стартует, а с тем, что она пытается запуститься, падает, перезапускается или ждёт таймаут.

Проверить упавшие службы можно так:

systemctl --failed --no-pager

Если всё нормально, вывод будет примерно таким:

0 loaded units listed.

Если есть проблемные службы, нужно посмотреть статус конкретной службы:

sudo systemctl status имя_службы --no-pager

Например:

sudo systemctl status nginx --no-pager

Важно: не перезапускайте службы наугад. Сначала посмотрите статус и логи, чтобы понять причину ошибки.

Смотрим ошибки текущей загрузки

Чтобы посмотреть предупреждения и ошибки именно с момента текущей загрузки, используйте journalctl с параметром -b:

journalctl -b -p warning..err -n 50 --no-pager

Что означают параметры:

• -b — показывать записи текущей загрузки;

• -p warning..err — показывать предупреждения и ошибки;

• -n 50 — вывести последние 50 строк;

• --no-pager — не открывать вывод в постраничном просмотрщике.

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

Как проверить конкретную службу

Если в systemd-analyze blame, critical-chain или systemctl --failed видно подозрительную службу, проверьте её отдельно.

Статус службы:

sudo systemctl status имя_службы --no-pager

Логи службы за текущую загрузку:

journalctl -u имя_службы -b --no-pager

Например, для SSH:

sudo systemctl status ssh --no-pager
journalctl -u ssh -b --no-pager

Для службы, которая долго стартует, особенно важны сообщения о таймаутах, ошибках конфигурации, недоступных файлах и ожидании сети.

Что делать, если служба долго запускается

Если вы нашли службу, которая замедляет загрузку, не стоит сразу отключать её. Сначала нужно понять, нужна ли она серверу.

Порядок проверки:

1. Посмотреть статус службы через systemctl status.

2. Посмотреть логи через journalctl -u.

3. Понять, к чему относится служба: сеть, база, веб-сервер, обновления, мониторинг, панель управления.

4. Проверить конфигурацию службы, если она падает или долго ждёт ресурс.

5. Только после этого решать: исправлять, отключать или менять порядок запуска.

Если служба не нужна, её можно отключить из автозагрузки:

sudo systemctl disable имя_службы

Если нужно сразу остановить её в текущей сессии:

sudo systemctl stop имя_службы

Осторожно: не отключайте ssh, сетевые службы, firewall, базу данных и веб-сервер, если не уверены в последствиях. Можно быстро устроить себе квест «почему я больше не могу зайти на VPS».

Когда задержка при загрузке считается проблемой

Не каждая задержка требует срочных действий. Если VPS загружается за 10–30 секунд и службы работают нормально, это обычно не проблема.

Повод разбираться глубже появляется, если:

• сервер после перезагрузки долго не доступен по SSH;

• сайт поднимается через несколько минут после старта VPS;

• в systemd-analyze blame есть службы с десятками секунд или минутами;

• в systemctl --failed есть ошибки;

• в journalctl -b видны таймауты и повторные попытки запуска;

• после каждого reboot ситуация повторяется.

Если задержка появляется один раз после обновления ядра или установки пакетов, это ещё не всегда неисправность. Но регулярные задержки лучше не игнорировать.

Частые причины медленной загрузки VPS

• Ожидание сети

  Некоторые службы стартуют только после появления сети. Если сеть или DNS отвечают медленно, запуск может задерживаться.

• Проблемы с mount-точками

  Если в /etc/fstab указан недоступный диск или раздел, система может ждать таймаут при загрузке.

• Ошибки в конфигурации службы

  Сервис может долго пытаться стартовать, падать и перезапускаться.

• Тяжёлые пользовательские сервисы

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

• Проблемы после обновлений

  После обновления пакетов могут измениться зависимости, права, конфиги или порядок запуска служб.

Полезные команды для анализа загрузки

Частые ошибки при диагностике

• Смотреть только systemd-analyze blame

  blame полезен, но не всегда показывает реального виновника задержки. Его лучше сравнивать с critical-chain.

• Отключать службу без понимания

  Перед отключением нужно понять, за что отвечает служба. Иначе можно отключить сеть, SSH, базу данных или важный компонент панели.

• Игнорировать journalctl

  Время запуска показывает симптом, а логи часто объясняют причину: ошибка конфига, недоступный файл, таймаут, проблема прав.

• Путать разовую задержку с постоянной проблемой

  После обновлений или первой загрузки задержка может быть разовой. Если она повторяется после каждого reboot, нужно разбираться.

Итоги

• Посмотрели общее время загрузки через systemd-analyze.

• Нашли самые медленные службы через systemd-analyze blame.

• Разобрали критическую цепочку загрузки через critical-chain.

• Проверили упавшие службы через systemctl --failed.

• Посмотрели ошибки текущей загрузки через journalctl -b.

• Разобрали, почему службу нельзя отключать без понимания её роли.

Вывод: чтобы понять, какие службы замедляют загрузку VPS, нужно смотреть не одну команду, а связку: systemd-analyze, blame, critical-chain, systemctl --failed и journalctl. Так можно увидеть не только долгие службы, но и реальные причины задержек.