Оптимізація часу завантаження Linux-сервера

Перезавантаження сервера - це операція, яку адміністратори зазвичай намагаються виконувати якомога рідше, але іноді все ж доводиться це робити. Так, процедура не складна і часто досить нешкідлива. Однак, якщо після reboot машина кілька хвилин не повертається до роботи, це може стати причиною цілком суттєвих проблем. Погодьтеся, виглядає не дуже, коли ти вирішив "швиденько" перезавантажити сервер, а натомість отримав кілька хвилин прискореного серцебиття та пару десятків сивих волосків.

При цьому повільне завантаження Linux-сервера далеко не завжди означає брак процесорних ресурсів або повільний диск. Сервер навіть може мати NVMe та досить швидкий процесор, але втрачати хвилину через один сервіс, який чекає на мережу, неіснуючий пристрій або файлову систему.

Тому оптимізація завантаження Linux часто стає необхідністю. І починати її слід не з відключення всього підряд, а з вимірювання цілком конкретних показників, які покажуть, на якому етапі виникає затримка.

Загалом, зайві 30-60 секунд під час завантаження сервера швидко перетворюються на цілком помітну проблему, яку ми й спробуємо усунути в цій статті.

 

 

 

 

Процес завантаження Linux

Якщо сильно спростити, то завантаження Linux проходить через кілька послідовних етапів:

 

 

Спочатку BIOS або UEFI ініціалізує обладнання та передає керування завантажувачу, зазвичай GRUB. Той завантажує в пам’ять ядро Linux та initramfs. Ядро запускається, ініціалізує основні підсистеми та підключає доступні на цьому етапі драйвери.

Далі до роботи приступає initramfs - це свого роду тимчасове мінімальне середовище, яке допомагає підготувати систему до роботи зі справжньою кореневою файловою системою. Тут можуть завантажуватися додаткові модулі, виявлятися диски, збиратися RAID-масиви або відкриватися зашифровані розділи. Після монтування кореневої файлової системи управління переходить до systemd.

На фізичному сервері час роботи BIOS/UEFI та ініціалізації обладнання може займати значну частину всього процесу завантаження. У VPS цей етап частково залежить від гіпервізора і зазвичай відбувається поза межами самої гостьової Linux-системи.

Далі systemd запускає системні сервіси та приводить систему до потрібного стану (targets). Причому сервіси не вишиковуються в одну довгу чергу, оскільки, якщо залежності дозволяють, кілька завдань виконуються паралельно. Тому сервіс із часом запуску 15 секунд зовсім не обов’язково затримує готовність системи на ті самі 15 секунд.

Ось цю частину завантаження вже зручно аналізувати за допомогою такого інструменту, як systemd-analyze. Перейдемо ж до конкретного аналізу.

 

 

 

 

Спочатку вимірюємо час завантаження

Отже, починати діагностику варто з найпростішої команди:

systemd-analyze

або:

systemd-analyze time

 

Відповідь виглядатиме приблизно так:

Startup finished in 1.842s (kernel) + 5.731s (userspace) = 7.573s
multi-user.target reached after 5.214s in userspace

 

systemd-analyze окремо показує час ядра, initrd та userspace, якщо відповідні етапи присутні. При цьому результат не можна сприймати буквально як момент повної готовності всіх додатків. Systemd вимірює проходження певних етапів запуску системи, а окремі сервіси після цього ще можуть продовжувати ініціалізацію.

Але вже тут можна визначити напрямок подальшого пошуку, оскільки якщо, наприклад, ядро запускається за дві секунди, а простір користувача займає хвилину, то, очевидно, немає сенсу починати з параметрів GRUB або збірки власного ядра, оскільки проблема майже напевно лежить вище.

 

 

 

 

Як зрозуміти, на якому етапі гальмується завантаження Linux

Перш ніж шукати конкретний повільний сервіс, потрібно зрозуміти, де взагалі втрачається час. Затримка може з’явитися ще до запуску systemd, наприклад, коли ядро довго ініціалізує пристрій, initramfs намагається знайти кореневу файлову систему або система чекає на недоступний диск із /etc/fstab.

Є й менш очевидний варіант, коли Linux уже майже завантажився, SSH вже доступний, але потрібна програма "оживає" лише через півхвилини. І тут проблема лежить десь вище за ланцюжком - наприклад, сервіс чекає на базу даних, контейнери або завершення міграцій.

Тому спочатку корисно визначити проблемний етап, а вже потім розбирати окремі units. Ми зібрали всі базові інструменти для цієї роботи в одну наочну та зручну таблицю. Звісно, вона не вичерпна, та й не може такою бути, але принаймні почати з неї можна.

Де втрачається час	Можлива причина	Що перевірити
Ядро (Kernel)	повільна ініціалізація драйверів, дисків або віртуальних пристроїв	dmesg, journalctl -b -k
Initramfs / Initrd	LVM, RAID, шифрування, очікування диска або пошук root FS	ранні журнали завантаження, конфігурація initramfs
Userspace	повільні systemd units, залежності між ними	systemd-analyze, systemd-analyze blame
Мережа	DHCP, налаштування інтерфейсу, очікування wait-online	networkctl, NetworkManager, журнали мережевих служб
Монтування	неправильний UUID, відсутній диск, недоступний мережевий mount	/etc/fstab, lsblk, findmnt
Застосунок запускається із затримкою	очікування бази даних, запуск контейнерів, міграції застосунку, внутрішня ініціалізація	systemctl status, journalctl -u, журнал застосунку

 

Якщо затримка відбувається в userspace, то можна перейти до окремих одиниць systemd. Для початку подивимося, які з них активувалися довше за інші за допомогою команди:

systemd-analyze blame

 

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

systemd-analyze blame --no-pager | head -20

У результаті ви повинні побачити приблизно таку відповідь:

21.384s systemd-networkd-wait-online.service
 8.912s mysql.service
 3.421s docker.service
 1.204s ssh.service

 

Тепер уже видно, на що звертати увагу. У прикладі найбільше виділяється systemd-networkd-wait-online.service, оскільки його активація зайняла понад 21 секунду. Але тут легко зробити неправильний висновок.

systemd-analyze blame показує тривалість активації кожного unit. Цей час не можна безпосередньо вважати затримкою всього завантаження, адже systemd запускає безліч незалежних unit паралельно, тому поки один сервіс чекає 21 секунду, поруч можуть запускатися інші.

Виходить, що відключення першого рядка з blame зовсім не гарантує, що сервер завантажиться на 21 секунду швидше. Щоб знайти затримки, які дійсно лежать на шляху до готової системи, потрібно переглянути залежності та критичний ланцюжок завантаження.

 

 

 

 

Шукаємо критичний ланцюжок

Команда systemd-analyze blame добре показує повільні модулі, але для діагностики завантаження Linux цього замало. Нас цікавить інше питання: які з цих затримок дійсно впливають на момент, коли система досягає потрібного стану?

Для цього є окрема команда:

systemd-analyze critical-chain

Вона показує критичний ланцюжок завантаження, тобто послідовність units, час запуску яких пов’язаний із залежностями та впливає на досягнення обраного target.

Умовний висновок може виглядати так:

multi-user.target @18.921s
└─docker.service @12.412s +6.401s
  └─network-online.target @12.390s    └─systemd-networkd-wait-online.service @2.341s +10.032s

 

Ось тут уже є конкретний слід. docker.service очікує на network-online.target, а той досягається лише після завершення systemd-networkd-wait-online.service. Останній у нашому прикладі активується приблизно через десять секунд.

Виходить ланцюжок, який можна розбирати зверху вниз. Замість довгого списку повільних сервісів ми бачимо пов’язані між собою units і можемо шукати місце, де затримка дійсно поширюється далі в процесі завантаження.

При цьому critical-chain теж не варто сприймати як повний граф завантаження. Ця команда показує критичну за часом гілку залежностей, але паралельно з нею systemd може виконувати безліч інших завдань. Для першого пошуку вузького місця цього зазвичай достатньо.

 

Як перевірити, чому конкретний service systemd запускається із запізненням

Припустимо, підозрілий unit знайдено, і тепер потрібно з’ясувати, що з ним відбувається: коли він запускається, скільки часу займає активація та від яких інших units він залежить.

Почати найпростіше зі статусу:

systemctl status docker.service

Тут видно поточний стан сервісу, час його запуску та останні повідомлення журналу. Якщо інформації замало, можна переглянути всі властивості unit:

systemctl show docker.service

 

Наступний крок - це пошук залежностей:

systemctl list-dependencies docker.service

Ця команда покаже одиниці, пов’язані із запуском обраного сервісу, але іноді цікавіше подивитися й у зворотному напрямку:

systemctl list-dependencies --reverse docker.service

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

 

Одного факту, що unit витратив десять або двадцять секунд, недостатньо, оскільки потрібно знайти причину очікування та зрозуміти його місце в ланцюжку завантаження. Іноді проблема дійсно може бути всередині сервісу, але іноді він просто стоїть у черзі за іншим unit - і шукати причину потрібно вже там.

 

 

 

Мережа як основна причина затримок завантаження

Однією з найпоширеніших причин тривалого завантаження Linux-сервера є очікування готовності мережі. У результатах systemd-analyze при цьому зазвичай з’являється один із двох сервісів:

systemd-networkd-wait-online.service

або, якщо мережа керується через NetworkManager:

NetworkManager-wait-online.service

 

Логіка у них проста. systemd може вважати базове налаштування мережі завершеним раніше, ніж потрібний інтерфейс дійсно отримає адресу і з’єднання стане придатним для роботи. wait-online затримує досягнення network-online.target до виконання заданих мережевих умов.

Таке очікування необхідне деяким системам, адже, наприклад, під час завантаження може знадобитися мережевий файловий ресурс, а окремий сервіс здатний нормально запуститися лише після появи робочого з’єднання. Але на звичайному VPS ці кілька секунд очікування іноді виявляються абсолютно зайвими.

Проблеми починаються, коли очікуваний стан мережі довго не настає: DHCP не відповідає, у конфігурації зберігся старий інтерфейс, додатковий NIC відключений - у підсумку система продовжує чекати до виконання умови або закінчення тайм-ауту.

 

Щоб перевірити саме цей сценарій, спочатку подивимося, що пов’язано з network-online.target:

systemctl list-dependencies network-online.target

 

Поточний стан інтерфейсів під час використання systemd-networkd можна перевірити так:

networkctl

 

Також корисно відразу перевірити за допомогою звичайних мережевих команд:

ip addr
ip route

 

А якщо сервер використовує NetworkManager, тоді перевіряємо пристрої та збережені підключення:

nmcli device status
nmcli connection show

 

Причини, через які wait-online може затримувати завантаження на десятки секунд, бувають різними, причому частину з них після першого погляду на конфігурацію мережі легко пропустити. Наприклад:

• у конфігурації залишився інтерфейс, якого вже немає;
• інтерфейс не отримує carrier;
• DHCP-сервер відповідає занадто довго або взагалі недоступний;
• старий мережевий профіль намагається автоматично активуватися;
• система очікує налаштування IPv4 або IPv6;
• додатковий мережевий інтерфейс вважається обов’язковим;
• якийсь сервіс вимагає network-online.target, хоча здатний працювати без очікування повністю готової мережі.

 

Особливо неприємним є останній випадок, коли з самою мережею все може бути в повному порядку, але одна зайва залежність змушує процес завантаження чекати на network-online.target.

Тому наступна команда може усунути затримку:

systemctl disable systemd-networkd-wait-online.service

 

Але застосовувати її наосліп не варто! Після вимкнення сервер дійсно може почати завантажуватися швидше, а ось залежний сервіс може отримати доступ до мережі пізніше, ніж розраховує. У результаті проблема просто перейде з етапу завантаження до журналу цього сервісу.

 

Спочатку краще з’ясувати, кому взагалі потрібен network-online.target. Для зворотного перегляду залежностей підійде команда:

systemctl list-dependencies --reverse network-online.target

 

Якщо з’ясується, що гарантовано готова мережа перед запуском цих служб не потрібна, тоді вже є сенс переглядати залежності або налаштування wait-online.

 

 

 

 

Коли проблема не в службі, а в timeout

Іноді сама тривалість затримки вже підказує напрямок пошуку.

Так, якщо завантаження щоразу завмирає приблизно на однаковий час - наприклад, близько 30, 60 або 90 секунд, то варто шукати компонент, який очікує на подію до закінчення певного timeout.

Типовий сценарій виглядає так:

 

 

Причиною може бути відсутній або неправильно прописаний диск, недоступний мережевий ресурс, DHCP, неправильно налаштований mount або сервіс, що очікує на якийсь зовнішній ресурс.

Саме тому під час діагностики корисно звертати увагу не тільки на помилки, а й на підозріло повторювані інтервали часу.

 

 

 

 

Виммикаємо непотрібні служби

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

Список увімкнених unit-файлів можна отримати командою:

systemctl list-unit-files --state=enabled

Але статус enabled сам по собі ще нічого не говорить про те, чи можна вимкнути службу. Спочатку варто перевірити, що вона робить і з якими units пов’язана:

systemctl status ім’я.service
systemctl list-dependencies ім’я.service

 

Нагадаємо, що корисно перевірити залежності й у зворотному напрямку, адже так видно, хто може розраховувати на цю службу:

systemctl list-dependencies --reverse ім’я.service

 

Якщо служба на сервері дійсно не використовується, то її автозапуск можна вимкнути:

sudo systemctl disable ім’я.service

 

При цьому disableне забороняє запуск служби повністю, і її, як і раніше, можна буде запустити вручну. А в деяких випадках вона може активуватися через інші механізми systemd, наприклад, через сокет або активацію D-Bus.

Однак є й більш жорсткий варіант - повне відключення служби:

sudo systemctl mask ім’я.service

 

mask пов’язує unit із /dev/null, тому systemd блокує його звичайний запуск. Це вже інструмент для випадків, коли служба взагалі не повинна запускатися. Використовувати його лише заради економії кількох сотень мілісекунд не має сенсу.

Також варто бути обережнішими з мережевими службами, такими як SSH, mount-одиниці, cloud-init та агентами віртуалізації. Частина з них потрібна лише під час завантаження сервера, тому після запуску системи може помилково здатися, що ці служби взагалі нічого не роблять.

 

Після всіх змін варто перезавантажити сервер і знову виконати systemd-analyze, оскільки будь-яка оптимізація має сенс лише тоді, коли затримка дійсно зникла, а всі необхідні служби після перезавантаження залишилися працездатними.

 

 

 

 

Перевіряємо помилки поточного завантаження

Іноді затримка виникає не тому, що якась служба повільна сама по собі, а тому, що система може кілька десятків секунд чекати на ресурс, якого взагалі не існує. Щоб виключити цей варіант, перевіримо кілька журналів:

Почнемо з загального:

systemctl --failed

Після цього варто перевірити журнал поточного завантаження:

journalctl -b

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

journalctl -b -p warning

Тут можна виявити помилки монтування, проблеми з пристроями, мережевими інтерфейсами, драйверами та службами.

 

Якщо підозра падає на конкретний unit, то зручніше буде відразу обмежити вибірку з журналу за допомогою того самого фільтра:

journalctl -b -u ім’я.service

Наприклад:

journalctl -b -u systemd-networkd-wait-online.service

Очевидно, що так шукати причину зазвичай простіше, ніж переглядати весь boot journal вручну.

 

 

 

 

Перевіряємо /etc/fstab та відсутні диски

Затримка під час завантаження може бути спричинена помилкою, допущеною під час налаштування дисків у /etc/fstab. Таке часто трапляється після змін у конфігурації дисків, коли пристрій уже видалено або відключено, а запис для його автоматичного монтування залишився.

Наприклад:

UUID=xxxx /mnt/storage ext4 defaults 0 2

Під час наступного завантаження systemd спробує знайти пристрій із вказаним UUID і змонтувати його. Але якщо цього диска насправді вже немає, то система може витратити час на очікування його появи. І іноді саме звідси беруться підозрілі паузи тривалістю у кілька десятків секунд.

Щоб виключити цей варіант, спочатку переглянемо доступні файлові системи та їхні UUID за допомогою команди:

lsblk -f

UUID можна додатково перевірити за допомогою:

blkid

 

Тепер перевіримо сам файл /etc/fstab:

findmnt --verify

Якщо в fstab вказано UUID, якого немає серед доступних пристроїв, то цей запис варто перевірити в першу чергу.

При цьому видаляти його відразу необов’язково. Для додаткового диска, відсутність якого не заважає роботі сервера, можна використовувати параметр nofail. Тоді помилка монтування такого сховища не повинна робити його обов’язковою умовою успішного завантаження.

 

Є й інші варіанти. Наприклад, x-systemd.automount дозволяє монтувати файлову систему при першому зверненні до неї, а x-systemd.device-timeout= задає час, протягом якого systemd чекатиме на появу пристрою.

Ну і для необов’язкового архівного диска така конфігурація може бути цілком обґрунтованою:

UUID=xxxx /mnt/archive ext4 defaults,nofail,x-systemd.device-timeout=5s 0 2

З критичними файловими системами ситуація дещо інша. Так, якщо на розділі зберігаються дані PostgreSQL або Docker, приховувати проблему з його доступністю за допомогою nofail заради швидшого завантаження сервера досить небезпечно.

 

 

 

 

Якщо час втрачається на етапі ядра

Іноді затримка виникає ще до запуску systemd. Якщо systemd-analyze показує помітний час на етапі kernel, то шукати повільний сервіс вже немає сенсу, адже проблема, очевидно, лежить раніше в ланцюжку завантаження.

Почати пошук у такому випадку можна з повідомлень ядра:

dmesg

А для поточного завантаження зручно використовувати журнал ядра:

journalctl -b -k

Він показує повідомлення ядра лише для поточного завантаження. Це особливо корисно, якщо частина ранніх повідомлень уже зникла з kernel ring buffer і вивід dmesg виявився неповним.

 

У журналі варто шукати такі події, як:

• помилки ініціалізації накопичувачів;
• повідомлення про timeout пристроїв;
• проблеми з драйверами;
• помилки завантаження firmware;
• повторні спроби ініціалізації обладнання;
• тривале виявлення дисків, контролерів та інших пристроїв зберігання даних;
• проблеми з віртуальними пристроями;
• незвично великі паузи між сусідніми повідомленнями.

Останній пункт часто дає хороший орієнтир. Повідомлення саме по собі може виглядати цілком нормально, але якщо наступний рядок з’явився через 20 секунд, то варто з’ясувати, чим ядро займалося протягом цього проміжку часу.

 

Можна відразу вивести повідомлення зі зручними для порівняння часовими мітками за допомогою команди:

journalctl -b -k -o short-monotonic

Тут уже простіше буде помітити місце, де нормальний потік повідомлень раптово переривається довгою паузою.

 

Як ми вже побіжно згадували вище, набір можливих причин залежить і від типу сервера. У VPS ядро працює з віртуальним обладнанням, яке надає гіпервізор, тому частина фізичних проблем прихована від гостьової системи. А ось на bare metal доводиться враховувати реальні диски, контролери, мережеві карти, firmware та інше обладнання.

Якщо затримка виявилася саме тут, то подальша діагностика зазвичай базується на повідомленнях безпосередньо перед тимчасовим розривом і відразу після нього.

 

 

 

 

Initramfs і ядро: копатися варто не завжди

Нагадаємо, що initramfs - це тимчасова файлова система, яку ядро використовує на ранньому етапі завантаження. У ній містяться компоненти, необхідні для підготовки та монтування справжньої кореневої файлової системи, такі, наприклад, як драйвери накопичувачів, інструменти LVM, модулі програмного RAID або засоби роботи з зашифрованими розділами.

Але склад initramfs можна оптимізувати. Можна прибрати непотрібні модулі, змінити спосіб його формування і тим самим трохи скоротити час раннього завантаження. Щоправда, потенційний виграш тут зазвичай невеликий, а помилка може призвести до того, що система взагалі не знайде root FS після перезавантаження.

Особливо обережно слід працювати з серверами, де використовуються LVM, програмний RAID, шифрування дисків або нестандартна конфігурація сховища. У таких випадках вміст initramfs безпосередньо пов’язаний із можливістю завантажити систему.

На звичайному VPS втручатися сюди заради оптимізації має сенс лише тоді, коли діагностика дійсно вказує на затримку на етапі initramfs. Тому якщо systemd-networkd-wait-onlineзабирає 25 секунд, а весь ранній етап завантаження займає пару секунд, починати з перекомпіляції initramfsявно зарано, і спочатку варто розібратися з великими затримками. Адже економія кількох сотень мілісекунд мало що змінить, якщо далі по ланцюжку система десятки секунд чекає на мережу, диск або завислий сервіс.

 

 

 

 

Візуалізуємо завантаження сервера

Усе описане вище, усі ці списки та ланцюжки залежностей зручні, доки кількість units залишається досить невеликою. Але на сервері з десятками сервісів текстовий вивід швидко розростається, і зрозуміти загальну картину стає набагато складніше. Тут стане в нагоді ще одна можливість утиліти systemd-analyze - побудова часової діаграми завантаження.

Створити її можна однією командою:

systemd-analyze plot > boot.svg

У результаті з’явиться файл boot.svg, який можна відкрити звичайним браузером. На діаграмі завантаження сервера розкладено за часом: видно момент запуску кожного unit, тривалість його активації та роботу інших units у той самий період.

 

Приклад часової діаграми завантаження Linux

 

Ця діаграма наочно демонструє паралельність systemd. Сервіс із верхньої частини systemd-analyze blame може здаватися повільним, але на діаграмі виявиться, що весь цей час поруч запускалися інші компоненти і загальне завантаження він майже не затримував. І зворотна ситуація теж може бути помітна відразу, коли короткі окремо units можуть вишикуватися в довгу послідовність залежностей, де наступний починає роботу лише після завершення попереднього.

На сервері з Docker, PostgreSQL, Nginx, системами моніторингу, резервного копіювання та власними systemd units така візуалізація особливо корисна, адже кілька десятків рядків терміналу перетворюються на одну часову шкалу, за якою набагато простіше шукати підозрілі ділянки.

Тут добре підійде реальний фрагмент boot.svg із виділеним тривалим unit або ланцюжком залежностей. На такому прикладі різниця між часом окремого сервісу та його реальним впливом на завантаження помітна майже відразу.

 

 

 

 

Типові причини повільного завантаження Linux

Ми підходимо до кінця, і для швидкої діагностики всю описану вище методику можна звести до невеликої таблиці:

Симптом	Ймовірний напрямок пошуку	З чого почати
Тривале завантаження userspace	systemd unit	systemd-analyze blame
Кілька повільних units	залежності	systemd-analyze critical-chain
Тривале очікування мережі	wait-online, DHCP, інтерфейс	networkctl, nmcli
Пауза однакової тривалості під час кожного завантаження	timeout	journalctl -b
Проблема з'явилася після видалення диска	/etc/fstab	lsblk -f, findmnt --verify
Ядро завантажується надто довго	сховище, драйвер, пристрій	dmesg, journalctl -b -k
Є failed units	помилка служби або ресурсу	systemctl --failed
Linux завантажився, але сайт ще недоступний	застосунок, база даних, контейнери	журнали служб, health check

Така таблиця корисна ще й тим, що допомагає не починати діагностику не з того кінця, адже якщо userspace займає 40 секунд, то копатися в параметрах ядра зарано. Якщо systemd запускається миттєво, але PostgreSQL ще хвилину виконує відновлення, прискорення multi-user.target взагалі не вирішить вихідну проблему.

 

 

 

 

Наскільки швидко взагалі повинен завантажуватися Linux-сервер

На жаль, єдиного нормального часу завантаження не існує, оскільки очевидно, що невеликий VPS і фізичний сервер з RAID-контролером, кількома мережевими інтерфейсами та великим набором сервісів завантажуватимуться по-різному.

Та й досягнення multi-user.target ще не завжди означає, що сервер готовий до роботи, адже, наприклад, PostgreSQL може продовжувати відновлення після збою, Docker - запускати контейнери, а ваш додаток - виконувати міграції.

Тому корисніше визначити свою точку готовності. Для веб-сервера це може бути успішна відповідь Nginx на health check, для бази даних - можливість приймати підключення, а для інфраструктурного вузла критерієм стане доступність необхідних мережевих служб.

По суті, правильним і важливим є час відновлення сервера - той час, який минає від запуску машини до моменту, коли вона знову здатна виконувати свою роботу.

 

 

 

Отже, оптимізація часу завантаження Linux-сервера рідко вимагає екзотичних патчів ядра або радикального видалення системних компонентів. Найчастіше винуватцем виявляється цілком прозаїчна річ, така як очікування мережі, відсутній диск, непотрібний сервіс, неправильна залежність або занадто довгий timeout.

Головні інструменти для пошуку причин затримок завантаження вже є в системі. Це такі інструменти, як systemd-analyze, critical-chain, systemctl, journalctl, dmesg, lsblk та findmnt. Разом вони дозволяють розкласти завантаження на зрозумілі етапи та з’ясувати, куди насправді йдуть дорогоцінні секунди.

Найважливіше у всій цій роботі - не перетворювати прискорення завантаження на змагання за мінімальний показник, оскільки для робочого Linux-сервера стабільні 12 секунд кращі за нестабільні сім, а хороша оптимізація - це коли після reboot машина не просто швидше з’являється в мережі, а щоразу передбачувано повертається до повністю робочого стану.

 

 

 

 

FAQ або Поширені запитання про завантаження Linux

Скільки часу має тривати завантаження Linux-системи?

Єдиного стандарту немає і бути не може, оскільки час залежить від обладнання або віртуальної машини, конфігурації дисків, мережі та кількості служб, що запускаються. Набагато корисніше порівнювати конкретний сервер із його звичайним часом завантаження та шукати різкі відхилення.

 

Чому Linux довго завантажується?

Найчастіше причина пов’язана з очікуванням якогось ресурсу. Це може бути диск, мережевий інтерфейс, DHCP, файлова система або служба systemd. Затримка може виникнути й раніше - під час роботи ядра або initramfs.

 

Чому під час завантаження Linux щоразу виникає пауза на 60 або 90 секунд?

Однакова тривалість паузи часто вказує на якийсь тайм-аут. Система на щось чекає, не отримує очікуваної події й продовжує завантаження лише після закінчення заданого часу.

 

Чи може /etc/fstab уповільнювати завантаження?

Так. Наприклад, у /etc/fstab може залишитися запис про диск, який уже відключено. Під час завантаження система спробує знайти пристрій і деякий час чекатиме на його появу.

 

Чому повільна служба systemd не завжди уповільнює завантаження?

systemd запускає багато служб паралельно. Служба може активуватися 15 секунд, але в цей же час система займається іншими завданнями. Тому тривалість запуску окремого unit і його вплив на загальний час завантаження - це різні речі.

 

Чи небезпечно відключати служби заради прискорення завантаження?

Залежить від служби. Відключення дійсно непотрібної служби зазвичай не створює проблем, але втручання в роботу мережі, файлових систем, SSH або компонентів віртуалізації може призвести до збоїв після перезавантаження. Спочатку потрібно з'ясувати призначення служби та її залежності.