Время загрузки сервера – один из тех аспектов администрирования Linux, которому часто не уделяют должного внимания. Однако оптимизация процесса загрузки может значительно снизить время простоя при перезагрузках, что критически важно для сервисов с высокими требованиями к доступности.

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

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

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

Шаг 1: Анализ времени загрузки

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

Использование systemd-analyze

Если ваша система использует systemd (большинство современных дистрибутивов), в вашем распоряжении мощный инструмент systemd-analyze:

# Базовый анализ времени загрузки
$ systemd-analyze time
Startup finished in 1.395s (kernel) + 4.893s (userspace) = 6.289s
graphical.target reached after 4.702s in userspace

# Подробный анализ времени, занятого каждой службой
$ systemd-analyze blame
1.630s NetworkManager-wait-online.service
1.106s systemd-networkd-wait-online.service
889ms mysql.service
615ms postgresql@12-main.service
405ms apache2.service
371ms snapd.service
287ms udisks2.service
256ms accounts-daemon.service
239ms dev-mapper-ubuntu\x2d\x2dvg\x2dswap_1.swap
...

# Создание SVG-диаграммы загрузки системы
$ systemd-analyze plot > boot-analysis.svg

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

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @4.702s
└─multi-user.target @4.702s
  └─mysql.service @3.813s +889ms
    └─network.target @3.808s
      └─NetworkManager.service @3.250s +557ms
        └─dbus.service @3.241s
          └─basic.target @3.198s
            └─sockets.target @3.198s
              └─snapd.socket @3.197s +1ms
                └─sysinit.target @3.193s
                  └─apparmor.service @2.773s +419ms
                    └─local-fs.target @2.772s
                      └─run-user-1000.mount @4.700s
                        └─local-fs-pre.target @2.766s
                          └─systemd-tmpfiles-setup-dev.service @1.186s +1.578s
                            └─kmod-static-nodes.service @1.174s +10ms
                              └─systemd-journald.socket @1.169s
                                └─system.slice @1.169s
                                  └─-.slice @1.169s

Анализ загрузки в SysVinit системах

Если вы работаете со старыми системами, которые используют SysVinit вместо systemd, есть альтернативные способы анализа:

# Проверка времени загрузки в SysVinit
$ dmesg | grep "Booting Linux"
$ dmesg | grep "Freeing unused kernel"
$ last reboot

# Добавление временных меток в логах для анализа скорости запуска сервисов
# Редактируем /etc/init.d/{service-name} и добавляем:
echo "$(date +%s.%N): Starting service" >> /var/log/boot-time.log

Использование bootchart

Для систем с и без systemd можно использовать bootchart, который создает графические отчеты о процессе загрузки:

# Установка bootchart в Debian/Ubuntu
$ sudo apt install bootchart

# Установка в RHEL/CentOS/Fedora
$ sudo dnf install bootchart

# После установки и перезагрузки графики будут доступны в:
$ ls /var/log/bootchart/

Шаг 2: Отключение ненужных служб

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

Идентификация ненужных служб

На серверах часто устанавливается множество пакетов, которые запускают службы автоматически, даже если они не используются в вашем конкретном сценарии:

• Графические интерфейсы и подсистемы отображения – на серверах чаще всего не нужны
• Службы управления питанием – для физических серверов, которые постоянно включены
• Инструменты печати – например, CUPS обычно не используется на серверах
• Bluetooth и другие беспроводные службы – редко используются на серверном оборудовании
• Планировщики заданий – если используется только один из нескольких установленных
• Системы мониторинга или бэкапа – дублирующие функциональность другого ПО

Отключение служб в systemd

В systemd управление службами осуществляется с помощью следующих команд:

# Список активных служб
$ systemctl list-units --type=service --state=active

# Список всех служб и их состояния
$ systemctl list-unit-files --type=service

# Отключение службы (не будет автоматически запускаться)
$ sudo systemctl disable service-name.service

# Остановка службы немедленно (если она уже запущена)
$ sudo systemctl stop service-name.service

# Проверка статуса службы после изменений
$ systemctl status service-name.service

# Примеры часто отключаемых служб на серверах
$ sudo systemctl disable cups.service
$ sudo systemctl disable bluetooth.service
$ sudo systemctl disable ModemManager.service
$ sudo systemctl disable avahi-daemon.service
$ sudo systemctl disable NetworkManager-wait-online.service

Отключение служб в SysVinit

В системах, использующих SysVinit, процесс немного отличается:

# Проверка статуса служб
$ sudo service --status-all

# Отключение службы (зависит от дистрибутива)
# Debian/Ubuntu:
$ sudo update-rc.d service-name disable

# CentOS/RHEL (до версии 7):
$ sudo chkconfig service-name off

# Проверка после отключения
# Debian/Ubuntu:
$ ls -la /etc/rc*.d/*service-name*

Маскирование служб для полной блокировки

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

# Маскирование службы в systemd
$ sudo systemctl mask service-name.service

# Отмена маскирования при необходимости
$ sudo systemctl unmask service-name.service

Шаг 3: Параллельная загрузка служб

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

Параллельная загрузка в systemd

Systemd по умолчанию запускает службы параллельно, но вы можете оптимизировать этот процесс:

# Проверка текущих настроек параллелизации
$ systemctl show --property DefaultTimeoutStartSec
$ systemctl show --property DefaultTimeoutStopSec

# Настройка глобального тайм-аута для служб (редактирование /etc/systemd/system.conf)
[Manager]
DefaultTimeoutStartSec=90s
DefaultTimeoutStopSec=90s

# После изменения необходимо перезагрузить конфигурацию systemd
$ sudo systemctl daemon-reload

Оптимизация порядка запуска служб

Для более эффективного параллельного запуска можно оптимизировать зависимости между службами:

# Анализ зависимостей службы
$ systemctl list-dependencies service-name.service

# Создание пользовательской настройки для службы
$ sudo mkdir -p /etc/systemd/system/service-name.service.d/
$ sudo nano /etc/systemd/system/service-name.service.d/override.conf

# Пример содержимого override.conf для ослабления зависимостей:
[Unit]
# Убрать жёсткую зависимость
Requires=
# Заменить на более мягкую
Wants=dependent-service.service

# или для изменения порядка запуска без жёсткой зависимости:
[Unit]
After=
Before=

# Перезагрузка конфигурации после изменений
$ sudo systemctl daemon-reload

Параллельная загрузка в SysVinit

В системах с SysVinit параллельная загрузка обычно не включена по умолчанию, но её можно настроить:

# Редактирование конфигурации для дистрибутивов на основе Debian
$ sudo nano /etc/init.d/rc

# Найдите и измените параметр CONCURRENCY
CONCURRENCY=shell
# Изменить на:
CONCURRENCY=makefile

# Для CentOS/RHEL (старые версии) редактируем /etc/sysconfig/init
$ sudo nano /etc/sysconfig/init

# Найти и установить:
BOOTUP=parallel

Настройка пользовательских зависимостей

Для тонкой настройки порядка запуска и зависимостей служб можно создать пользовательские юниты:

# Создаем копию оригинального юнита:
$ sudo cp /lib/systemd/system/original-service.service /etc/systemd/system/

# Редактируем копию:
$ sudo nano /etc/systemd/system/original-service.service

# Добавляем или изменяем секцию [Unit]:
[Unit]
Description=My optimized service
# Нечеткая зависимость - хотим, но не требуем:
Wants=another-service.service
# Указание порядка запуска, но без зависимости:
After=network.target

# Или для ускорения использование условных зависимостей:
[Unit]
# Запускать только если сеть действительно доступна, а не ждать её:
Requires=network-online.target
# Использовать условие проверки файла:
ConditionPathExists=/path/to/needed/file.conf

# Перезагрузка конфигурации:
$ sudo systemctl daemon-reload

Шаг 4: Оптимизация конфигурации ядра

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

Оптимизация параметров загрузки ядра

Параметры ядра настраиваются в загрузчике системы (чаще всего GRUB):

# Редактирование конфигурации GRUB
$ sudo nano /etc/default/grub

# Добавление параметров для ускорения загрузки
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noatime nodiratime noresume"
# или
GRUB_CMDLINE_LINUX="quiet fastboot noatime nodiratime noresume"

# Обновление конфигурации GRUB
$ sudo update-grub # для Debian/Ubuntu
# или
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg # для RHEL/CentOS

Основные параметры ядра для ускорения загрузки:

• quiet – уменьшает вывод сообщений во время загрузки
• fastboot – пропускает проверку файловой системы при загрузке
• noresume – отключает функцию возобновления из спящего режима, что ускоряет загрузку
• noatime, nodiratime – отключает обновление времени доступа к файлам и каталогам
• intel_idle.max_cstate=1 – может ускорить загрузку на некоторых серверах Intel
• noapic, nolapic – на некоторых серверах отключение расширенного программируемого контроллера прерываний может ускорить загрузку

Настройка модулей ядра

Загрузка ненужных модулей ядра увеличивает время запуска. Можно отключить модули, которые не используются в вашей системе:

# Список загруженных модулей
$ lsmod

# Создание black list для ненужных модулей
$ sudo nano /etc/modprobe.d/blacklist.conf

# Добавление модулей в черный список (пример)
blacklist pcspkr     # PC спикер
blacklist bluetooth  # Bluetooth, если не используется
blacklist firewire   # FireWire, редко используется на серверах

# Для включения модулей в initramfs (для быстрой загрузки часто используемых)
$ sudo nano /etc/initramfs-tools/modules  # для Debian/Ubuntu
# или
$ sudo nano /etc/dracut.conf.d/modules.conf  # для RHEL/CentOS/Fedora

# Добавить нужные модули для раннего запуска
# modulename

# Обновление initramfs
$ sudo update-initramfs -u  # для Debian/Ubuntu
# или
$ sudo dracut -f  # для RHEL/CentOS/Fedora

Оптимизация параметров планировщика I/O

Планировщик ввода-вывода влияет на скорость загрузки, особенно для устройств SSD:

# Проверка текущего планировщика для всех дисков
$ cat /sys/block/*/queue/scheduler

# Настройка планировщика для SSD (рекомендуется deadline или none/noop)
$ echo deadline > /sys/block/sda/queue/scheduler

# Для постоянной настройки добавить в /etc/rc.local или создать правило udev
$ sudo nano /etc/udev/rules.d/60-scheduler.rules

# Пример правила udev для SSD:
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

# Для NVMe SSD часто лучше всего подходит none:
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"

Шаг 5: Оптимизация файловой системы

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

Выбор оптимальной файловой системы

Разные файловые системы имеют различные характеристики производительности:

• ext4 – хорошо сбалансированная файловая система, подходит для большинства случаев
• XFS – высокая производительность для больших файлов и больших файловых систем
• Btrfs – современная ФС с многими функциями, но может быть медленнее при загрузке
• ZFS – продвинутая ФС с множеством функций, но требует больше ресурсов при загрузке

# Проверка текущих файловых систем
$ df -T

# Оптимальные параметры монтирования для ускорения загрузки (редактируем /etc/fstab)
$ sudo nano /etc/fstab

# Пример оптимизированного раздела ext4
UUID=xxxxx-xxxx / ext4 defaults,noatime,nodiratime,commit=60 0 1

# Пример оптимизированного раздела XFS
UUID=xxxxx-xxxx /data xfs defaults,noatime,nodiratime,attr2,largeio,nobarrier 0 2

# После внесения изменений необходимо перемонтировать или перезагрузить
$ sudo mount -o remount /

Оптимизация параметров монтирования

Ключевые параметры монтирования для ускорения загрузки и работы системы:

• noatime, nodiratime – отключает обновление времени доступа, существенно ускоряя операции чтения
• commit=N – устанавливает интервал синхронизации с диском в секундах (стандартно 5)
• barrier=0, nobarrier – отключает барьеры записи (для систем с защищенным питанием)
• data=writeback – для ext4, может ускорить запись ценой снижения надежности при сбоях
• discard – для SSD, включает TRIM, но может замедлить загрузку; лучше использовать периодический fstrim

# Настройка периодического TRIM вместо discard (рекомендуется)
$ sudo systemctl enable fstrim.timer
$ sudo systemctl start fstrim.timer

Предварительная загрузка файлов

Для серверов с предсказуемым набором приложений можно настроить предварительную загрузку часто используемых файлов:

# Установка preload
$ sudo apt install preload  # Debian/Ubuntu
$ sudo yum install preload  # CentOS/RHEL

# Включение и запуск службы
$ sudo systemctl enable preload
$ sudo systemctl start preload

# Также можно создать скрипт предзагрузки для конкретных приложений
$ sudo nano /usr/local/bin/preload-apps.sh

#!/bin/bash
# Список файлов, которые нужно загрузить в кэш
cat /usr/bin/application1 > /dev/null
cat /usr/bin/application2 > /dev/null
cat /etc/application1/*.conf > /dev/null

# Сделать скрипт исполняемым
$ sudo chmod +x /usr/local/bin/preload-apps.sh

# Добавить в автозагрузку (через systemd service или rc.local)

Отключение журналирования для временных разделов

Для временных разделов, таких как /tmp, можно отключить журналирование для увеличения скорости:

# Редактирование /etc/fstab для /tmp
UUID=xxxxx-xxxx /tmp ext4 defaults,noatime,nodiratime,journal_async_commit 0 2

# Еще лучше - использовать tmpfs для временных разделов
tmpfs /tmp tmpfs defaults,size=2G,noatime 0 0

Бонус: Автоматизация оптимизации

Для систематической оптимизации множества серверов полезно автоматизировать процесс с помощью скриптов и инструментов управления конфигурацией. Это сделает оптимизацию более последовательной и сократит ручной труд.

Скрипт для базовой оптимизации

Ниже приведен пример скрипта, который автоматизирует основные шаги оптимизации:

#!/bin/bash
# optimize-boot.sh - Скрипт для оптимизации загрузки Linux-сервера

# Проверка наличия прав root
if [ "$(id -u)" -ne 0 ]; then
    echo "Этот скрипт должен быть запущен с правами root." >&2
    exit 1
fi

echo "Анализ текущего времени загрузки..."
systemd-analyze time
systemd-analyze blame > boot-blame-before.txt

echo "Отключение ненужных служб..."
SERVICES_TO_DISABLE=(
    "bluetooth.service"
    "cups.service"
    "avahi-daemon.service"
    "ModemManager.service"
    "NetworkManager-wait-online.service"
)

for service in "${SERVICES_TO_DISABLE[@]}"; do
    if systemctl is-enabled "$service" &> /dev/null; then
        echo "Отключение $service..."
        systemctl disable "$service"
        systemctl stop "$service"
    else
        echo "$service уже отключен или не существует."
    fi
done

echo "Оптимизация параметров ядра..."
if grep -q "GRUB_CMDLINE_LINUX_DEFAULT=" /etc/default/grub; then
    # Добавить параметры, если они еще не добавлены
    if ! grep -q "noatime" /etc/default/grub; then
        sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="noatime nodiratime noresume /' /etc/default/grub
        echo "Обновление параметров ядра в GRUB..."
        update-grub
    else
        echo "Параметры ядра уже оптимизированы."
    fi
else
    echo "ПРЕДУПРЕЖДЕНИЕ: Не найдена конфигурация GRUB_CMDLINE_LINUX_DEFAULT."
fi

echo "Настройка файловой системы..."
# Проверяем, есть ли уже оптимизации в /etc/fstab
if ! grep -q "noatime" /etc/fstab; then
    # Создаем резервную копию
    cp /etc/fstab /etc/fstab.backup
    # Добавляем параметры noatime,nodiratime к основным разделам
    sed -i 's/defaults/defaults,noatime,nodiratime/g' /etc/fstab
    echo "Файловая система оптимизирована. Бэкап сохранен в /etc/fstab.backup"
else
    echo "Параметры файловой системы уже оптимизированы."
fi

# Включаем таймер для TRIM (для SSD)
if [ -f /usr/lib/systemd/system/fstrim.timer ]; then
    systemctl enable fstrim.timer
    systemctl start fstrim.timer
    echo "Таймер TRIM активирован."
fi

echo "Оптимизация планировщика I/O..."
# Определить SSD диски
for disk in /sys/block/sd*; do
    if [ -f "$disk/queue/rotational" ] && [ "$(cat "$disk/queue/rotational")" -eq 0 ]; then
        echo "deadline" > "$disk/queue/scheduler"
        echo "Установлен планировщик deadline для $(basename "$disk")"
    fi
done

# Настройка для NVMe
for disk in /sys/block/nvme*; do
    if [ -f "$disk/queue/scheduler" ]; then
        echo "none" > "$disk/queue/scheduler"
        echo "Установлен планировщик none для $(basename "$disk")"
    fi
done

echo "Создание правил udev для планировщика I/O..."
cat > /etc/udev/rules.d/60-scheduler.rules << 'EOL'
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
EOL

echo "Перезагрузка службы для применения изменений..."
systemctl daemon-reload
udevadm control --reload-rules
udevadm trigger

echo "Оптимизация завершена. Рекомендуется перезагрузить систему."
echo "После перезагрузки запустите 'systemd-analyze time' для проверки результатов."

Использование Ansible для масштабной оптимизации

Для оптимизации множества серверов удобно использовать инструменты управления конфигурацией, такие как Ansible:

# Пример плейбука Ansible для оптимизации загрузки (boot-optimization.yml)
---
- name: Optimize Linux Server Boot Time
  hosts: linux_servers
  become: yes
  tasks:
    - name: Get current boot time stats
      shell: systemd-analyze time
      register: boot_time_before
      changed_when: false

    - name: Disable unnecessary services
      systemd:
        name: "{{ item }}"
        enabled: no
        state: stopped
      with_items:
        - bluetooth.service
        - cups.service
        - avahi-daemon.service
        - ModemManager.service
        - NetworkManager-wait-online.service
      ignore_errors: yes

    - name: Optimize GRUB parameters
      lineinfile:
        path: /etc/default/grub
        regexp: '^GRUB_CMDLINE_LINUX_DEFAULT="(.*)"'
        line: 'GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noatime nodiratime noresume"'
        backrefs: yes
      register: grub_updated

    - name: Update GRUB if changed
      command: update-grub
      when: grub_updated.changed

    - name: Optimize filesystem mount options
      mount:
        path: "{{ item.path }}"
        src: "{{ item.src }}"
        fstype: "{{ item.fstype }}"
        opts: "{{ item.options }},noatime,nodiratime"
        state: mounted
      with_items:
        - { path: "/", src: "UUID=your-root-uuid", fstype: "ext4", options: "defaults" }
        # Добавьте другие разделы по необходимости
      when: "'noatime' not in item.options"

    - name: Enable fstrim.timer for SSD
      systemd:
        name: fstrim.timer
        enabled: yes
        state: started
      ignore_errors: yes

    - name: Set scheduler for SSD devices
      copy:
        content: |
          ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
          ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
        dest: /etc/udev/rules.d/60-scheduler.rules

    - name: Reload udev rules
      shell: |
        udevadm control --reload-rules
        udevadm trigger

    - name: Show optimization summary
      debug:
        msg: "Boot optimization completed. Original boot time: {{ boot_time_before.stdout }}"

Заключение

Оптимизация времени загрузки Linux-сервера – не просто косметическое улучшение, а важный аспект обеспечения высокой доступности и эффективной работы системы. Следуя пяти ключевым шагам, описанным в этой статье, вы можете значительно сократить время запуска и улучшить общую производительность системы.

Подведем итоги основных шагов:

• Анализ времени загрузки – использование инструментов вроде systemd-analyze для выявления узких мест
• Отключение ненужных служб – удаление или деактивация компонентов, не требуемых для работы сервера
• Параллельная загрузка служб – оптимизация зависимостей и порядка запуска для более эффективного использования многоядерных процессоров
• Оптимизация конфигурации ядра – настройка параметров ядра и модулей для быстрого запуска
• Оптимизация файловой системы – выбор правильных файловых систем и параметров монтирования

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

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