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

1. Серія контенту:
2. Цей контент є частиною серії:
3. Огляд процесу запуску Linux-системи
4. Розуміння і використання SysVinit
5. Лістинг 1. Традиційні команди у файлі / etc / inittab, пов'язані з запуском
6. Лістинг 2. Розділ коментарів в традиційному скрипті SysVinit
7. Таблиця 1. Коментарі в секції INIT INFO скрипта SysVinit
8. Розуміння і використання механізмів запуску, керованих подіями
9. Лістинг 3. Conf-файл /etc/init/rcS.conf механізму Upstart.
10. Розуміння і використання systemd
11. Таблиця 2. Поширені типи елементів для systemd
12. Лістинг 4. Приклад конфігураційного файлу сервісу systemd
13. Моніторинг запуску системи і виконання скрипта
14. Малюнок 1. Фрагмент графічного представлення початкового завантаження, отриманий за допомогою утиліти...
15. Лістинг 5. Приклад скрипта для присвоєння нових унікальних імен вихідним файлів Bootchart
16. Висновок
17. Ресурси для скачування

Порівняння різних механізмів запуску Linux-систем

Серія контенту:

Цей контент є частиною # з серії # статей:

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії:

Слідкуйте за виходом нових статей цієї серії.

Огляд процесу запуску Linux-системи

Процес запуску Linux-системи - від включення харчування до стану повної працездатності - можна розділити на дві концептуально різні фази:

1. Початкова завантаження з будь-якого пристрою; завантаження і ініціалізація ядра Linux
2. Запуск додатків простору користувача (включаючи серверні процеси), монтування додаткових файлових систем, виконання додаткового конфігурації і настройки ядра, надання доступу до додаткових пристроїв

Основні кроки першої фази були описані в раніше опублікованій на developerWorks статті Подробиці процесу завантаження Linux (див. Розділ ресурси ). Ці кроки не сильно змінилися за минулі роки, за винятком використання завантажувача GRUB 2 (GRand Unified Bootloader 2), відмінностей в форматі і в використанні початкового RAM-диска, а також змін в першому процесі, запускається в просторі користувача (традиційно це процес init) . На першій фазі підвищення продуктивності відбувається головним чином завдяки вдосконаленню апаратних засобів (більш швидкі завантажувальні пристрої, швидші механізми доступу до пристроїв, більш швидкі і більш потужні процесори). Однак на другій фазі підвищення продуктивності майже повністю визначається сферою програмного забезпечення, і тут застосовується кілька різних підходів.

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

• Мінімізація: запуск лише найменшого набору необхідних сервісів.
• Лінійність: розуміння потреб кожного конкретного сервісу в інших сервісах (т. Н. Аналіз залежностей) і облік цих потреб в процесі запуску.
• Паралелізм: максимальне розширення можливостей для одночасного запуску незалежних сервісів (або ланцюжків пов'язаних сервісів).

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

Розуміння і використання SysVinit

Традиційний механізм запуску та вимикання системи, що використовується в Linux-системах, носить назву SysVinit. Як можна припустити за назвою SysVinit, його концептуальні витоки лежать в версії UNIX® під назвою Sys V (точніше, UNIX System V, Release 4 - SVR4), яка була випущена в 1989 році. Ініціалізації програма SysVinit читає файл / etc / inittab з метою ідентифікації набору сервісів, які повинні бути доступними в той момент, коли система досягає свого стану за замовчуванням (рівень runlevel за замовчуванням для системи) і команди, яку вона повинна виконати для досягнення цього стану. У системах, що використовують SysVinit, ця інформація задається за допомогою записів в файлі / etc / inittab (див. лістинг 1 ).

Лістинг 1. Традиційні команди у файлі / etc / inittab, пов'язані з запуском

si :: sysinit: /etc/init.d/rcS id: 5: initdefault: l5: 5: wait: /etc/init.d/rc 5

Перший рядок ідентифікує перший скрипт, який система повинна виконати при своїй ініціалізації. Другий рядок ідентифікує значення runlevel за замовчуванням після ініціалізації системи. У цьому прикладі значення runlevel за замовчуванням дорівнює 5; зазвичай це означає систему з повними мережевими і графічними можливостями. Третій рядок ідентифікує команду, яку система повинна використовувати для досягнення рівня runlevel 5.

При використанні механізму SysVinit каталог /etc/init.d містить скрипти оболонки, які запускають і зупиняють всі процеси системного рівня. Для кожного runlevel є власний каталог, що містить символьні посилання на певні скрипти оболонки в каталозі /etc/init.d, які слід запускати або зупиняти при вході в відповідний рівень runlevel або виході з нього. Третій рядок в лістингу 1 дає механізму SysVinit вказівку виконувати скрипти з цього каталогу, асоційовані з runlevel 5. Зазвичай це скрипти /etc/rc5.d, /etc/init.d/rc5.d або /etc/rc.d/rc5. d - в залежності від застосовуваного дистрибутива Linux.

Символьні посилання в каталозі рівня runlevel починаються з S або з K. S вказує, що даний скрипт повинен виконуватися з метою запуску асоційованого з ним системного процесу при вході системи в зазначений рівень runlevel; K вказує, що даний скрипт повинен виконуватися з метою завершення асоційованого з ним системного процесу при виході системи з цього рівня runlevel. Цілочисельне значення, наступне за S або за K, визначає порядок, в якому ці скрипти слід виконувати при вході в відповідний рівень runlevel або при виході з нього.

Якщо в каталог /etc/init.d додаються нові скрипти, то спеціальним чином відформатовані коментарі на початку кожного скрипта ідентифікують всі інші скрипти, від яких залежить даний скрипт, а також ідентифікують кожен рівень runlevel, з яким повинен бути асоційований даний скрипт. Команди та інші відомості, які повинні бути присутніми в цих скриптах, визначаються специфікацією LSB (Linux Standard Base), яка представляє собою стандарт, розроблений декількома авторами інших збірок Linux для гарантування сумісності скриптів SysVinit в різних дистрибутивах Linux. В лістингу 2 , Взятому з обговорення LSB-коментарів в init скрипти, показаний приклад такого розділу.

Лістинг 2. Розділ коментарів в традиційному скрипті SysVinit

### BEGIN INIT INFO # Provides: lsb-ourdb # Required-Start: $ local_fs $ network $ remote_fs # Required-Stop: $ local_fs $ network $ remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop OurDB # Description: OurDB is a very fast and reliable database # engine used for illustrating init scripts ### END INIT INFO

В таблиці 1 показана інформація, яку представляє кожна з цих записів.

Таблиця 1. Коментарі в секції INIT INFO скрипта SysVinit

Ключове слово Сенс Provides Логічне ім'я сервісу, що надається даним скриптом ініціалізації. Required-Start Логічні імена будь-яких інших сервісів, які повинні виконуватися з метою успішного запуску сервісу, визначеного в цьому скрипті ініціалізації. Required-Stop Логічні імена будь-яких інших сервісів, які повинні виконуватися з метою успішної зупинки сервісу, визначеного в цьому скрипті ініціалізації. Default-Start Рівні runlevel, на яких даний скрипт ініціалізації необхідно виконати для запуску визначається їм сервісу. Default-Stop Рівні runlevel, на яких даний скрипт ініціалізації необхідно виконати для зупинки визначається їм сервісу .. Short-Description і Description Коротке і більш докладний опис сервісу, асоційованого з командами в скрипті ініціалізації. Ці описи використовуються різними системними утилітами, які запитують і узагальнюють скрипти ініціалізації SysVinit.

Для запуску, зупинки та перерахування скриптів SysVinit можна скористатися командою / sbin / service. Для перерахування або зміни рівнів runlevel, з якими асоційовані ці скрипти, можна скористатися командою / sbin / chkconfig.

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

Що стосується продуктивності, то SysVinit виконує кілька скриптів оболонки в зазначеному порядку з метою досягнення заданого рівня runlevel. Виконання скриптів оболонки здійснюється відносно повільно і по суті пропонує послідовний механізм запуску. Це може збільшити тривалість початкового завантаження, оскільки немає ніякого способу для застосування потенційного паралелізму. Кожен скрипт оболонки, асоційований з цільовим рівнем runlevel, повинен виконуватися в порядку, визначеному числом в імені символьного посилання, яка вказує на цей скрипт. Запуск іншого сервісу не може розпочатися до тих, поки поточний сервіс не завершиться. Внаслідок цього системи, в яких використовується SysVinit, можуть найбільше виграти від інтеграції інструментів для моніторингу запуску і профілювання (описуваних в останньому розділі цієї статті, Моніторинг запуску системи і виконання скрипта ) З метою точного визначення часу, що витрачається кожним скриптом запуску.

Більш детальний опис механізму SysVinit в цілому міститься в статті Boot Linux Faster (Прискорення завантаження Linux) на сайті developerWorks (див. Розділ ресурси ).

Розуміння і використання механізмів запуску, керованих подіями

Механізм SysVinit зручний в роботі і легко налаштовується завдяки використанню скриптів оболонки для запуску і зупинки системних сервісів. Однак використання таких послідовних скриптів оболонки уповільнює механізм SysVinit і не забезпечує можливостей для паралельного запуску незв'язаних сервісів. Інша проблема полягає в тому, що скрипти, які запускають і зупиняють сервіси, виконуються тільки при запуску або виключенні системи - іншими словами, єдина подія, на яке вони реагують - це зміна рівнів runlevel системи. За небагатьма винятками (наприклад, сервіси, що запускаються іншими сервісами), це означає, що всі сервіси, які можуть вимагатися в системі, повинні постійно виконуватися і чекати запитів, які можуть ніколи не надійти.

Виконання невикористовуваних процесів неефективно - як з точки зору споживання ресурсів пам'яті і процесорів, так і з точки зору часу, який потрібен для їх первинного запуску. Сьогоднішні все більш гнучкі системи повинні бути в змозі функціонувати коректно і без збоїв в самих різних ситуаціях - в тому числі при переході від проводового підключення до мережі до безпровідного, при міграції між мережами, при змінах в апаратних засобах (додавання / видалення пристроїв зберігання даних і інших периферійних пристроїв).

Тут на сцену виходять керовані подіями механізми запуску, які спрацьовують точно в певний момент, виконуючи задані команди і запускаючи асоційовані сервіси при настанні відповідних подій в системі. Демони inetd і xinetd для різних мережевих сервісів представляють собою гарну аналогію для керованих подіями механізмів запуску, оскільки вони просто чекають настання певних подій (запити на мережеві з'єднання для керованих цими демонами сервісів), а потім запускають відповідний сервіс в міру необхідності. Керовані подіями механізми запуску забезпечують максимальну ступінь паралелізму під час запуску системи, дозволяючи кільком командам виконуватися одночасно у відповідь на подію, і поширюють цю динамічну здатність до реагування на середу виконання системи. Подія - це по суті строкове повідомлення, яке процес здатний відіслати у відповідь на зміну в стані будь-якого "суб'єкта", моніторинг якого здійснює цей процес. Процес відсилає повідомлення про подію одноразово.

Найвідомішим з керованих подіями механізмів запуску є Upstart - це механізм запуску, яка буде використовуватися в таких дистрибутивах Linux, як Ubuntu 9.10 і вище, RHEL6 (пов'язані дистрибутиви: (CentOS, Oracle Linux, Scientific Linux), Fedora 9-14, а також в багатьох інших дистрибутивах Linux. Upstart має зворотну сумісність з runlevel-моделлю SysVinit.

Механізм Upstart використовує т.зв. файли конфігурації завдань (conf-файли), які описують його реакцію на різні події - запуск, вимикання, переходи між рівнями runlevel і т. д. Зазвичай ці файли знаходяться в каталозі / etc / init, хоча з причин забезпечення сумісності деякі з них знаходяться в каталозі /etc/event.d. Всі створювані вами нові conf-файли в масштабі всієї системи повинні розміщуватися в каталозі / etc / init. Як правило, conf-файли мають розширення conf. Це текстові файли, які повинні містити як мінімум наступну інформацію.

• Події (одне або декілька), у відповідь на наступ яких цей conf-файл повинен виконати певну дію. Наприклад, запис start on startup говорить про те, що файл завдання повинен бути виконаний при отриманні інформації про подію startup, а запис stop on runlevel говорить про те, що файл завдання повинен зупинитися при отриманні будь-якої інформації про подію runlevel, наприклад, про зміні рівня runlevel системи.

• Розділ task або respawn, який містить як мінімум запис exec або розділ script із зазначенням команд, виконуваних у відповідь на події, якими ініціюється цей conf-файл. Запис exec виконує певну команду, зазвичай двійковий файл, з певним набором аргументів командного рядка. Розділ script, відомий як stanza-запис, містить команди, виконувані оболонкою, включаючи будь-які скрипти оболонки; вона повинні закінчуватися твердженням end script Механізм Upstart за допомогою ключових слів task і respawn управляє двома концептуальними класами завдань.

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

У розділі task conf-файлу Upstart також можна використовувати інші ключові слова для ідентифікації пристроїв виведення, скриптів для виконання перед основним розділом exec або script, скриптів для виконання після завершення основних розділів exec або script і т. Д. Розділ pre-start script містить команди , які використовуються для ініціалізації середовища, необхідної для команд script або exec, а розділ post-stop script містить команди, які використовуються для очищення або обробки поста після завершення команди exec або stanza-записи script. У conf-файлах можуть бути використані і багато інших команд Upstart (див. Розділ ресурси ).

Наприклад, в лістингу 3 показаний conf-файл Upstart з ім'ям /etc/init/rcS.conf, емулює механізм SysVinit. Для спрощення читання цього файлу я видалив з нього коментарі.

Лістинг 3. Conf-файл /etc/init/rcS.conf механізму Upstart.

start on runlevel [0123456] stop on runlevel [! $ RUNLEVEL] task export RUNLEVEL console output exec /etc/rc.d/rc $ RUNLEVEL

Цей conf-файл визначає завдання, яка виконує будь-які наявні скрипти SysVinit з каталогу, асоційованим з поточним рівнем runlevel.

Завдання Upstart можна запускати, зупиняти і перераховувати за допомогою команди / sbin / initctl. Ця команда показує завдання механізму Upstart, які виконуються в даний момент, а також їх поточний стан. Як додати нове завдання до послідовності ініціалізації системи досить просто створити відповідний conf-файл для цього сервісу і помістити цей файл в каталог / etc / init. Upstart версії 1.3 і вище також підтримує conf-файли, прив'язані до конкретного користувача. Ці файли розміщуються в підкаталозі init особистого каталогу користувача, однак ця опція використовується нечасто.

Розуміння і використання systemd

Точно так же, як механізм Upstart, здавалося, був покликаний витіснити механізм SysVinit з усіх Linux-систем, з часом з'явився інший, ще більш ефектний, більш вражаючий і більш ефективний механізм запуску: systemd (system daemon), першим автором якого є Леонард Путтерінг (Leonard Poettering). Механізм запуску системи systemd значно покращує запуск параллелізірованной системи завдяки розумінню забезпечують ресурсів, необхідних для різних сервісів. Крім того, systemd полегшує відстеження ресурсів для пов'язаних процесів і управління ними за рахунок використання механізму cgroups (control groups), який підтримується в ядрі Linux починаючи з пізніх випусків версії 2.6.

Більшість СУЧАСНИХ Linux-сервісів и асоційованіх з ними КЛІЄНТІВ Використовують для взаємодії между процесами сокети UNIX, включаючі шину обміну повідомленнями D-Bus, призначення для Повідомлень Загальне характеру, пов'язаних з апаратного засоби, и для локальних Повідомлень между Додатками. Если необхідні сокети існують (або шина D-Bus булу актівована), могут буті запущені будь Використовують їх сервіси, тому Механізм systemd спочатку створює всі сокети, Асоційовані з сервісамі, Які ви хочете запустіті на даній системе. Сервіси, які використовують ці ресурси, зазвичай блокуються доти, поки у них не виникає необхідність доставити або отримати повідомлення, тому вони можуть бути запущені або паралельно, або на вимогу відповідно до вхідними запитами.

Створення логічних ресурсів, що забезпечують можливість запуску сервісів, які могли б використовувати ці ресурси паралельно, не обмежена лише клієнтами і серверами. Навіть традиційно повільні фрагменти процесу запуску системи, такі як перевірка файлової системи на несуперечливість та її монтування, можуть використовувати цю модель для будь-яких файлових систем (крім кореневої файлової системи, оскільки вона завжди потрібна всім), за умови її поєднання з механізмами доступу до файлової системи на вимогу, такими як autofs. Після того, як файлова система змонтована, можна використовувати події зміни файлу або файлової системи для ініціювання інших дій за допомогою таких механізмів ядра, як fanotify і fsnotify.

Механізм запуску systemd управляє т. Н. елементами (unit). Щоб задовольнити різні типи потреб у відношенні ініціалізації і запуску, механізм systemd підтримує різні типи елементів. Пояснення до найбільш поширеним з цих елементів наведені в таблиці 2 .

Таблиця 2. Поширені типи елементів для systemd

Тип елемента Пояснення automount Визначає точку монтування файлової системи, яка використовується механізмом доступу до файлової системи на вимогу, таким як autofs. Для кожного елемента automount є відповідний йому елемент mount. device Являє фізичний пристрій, для якого існує правило udev. mount Визначає стандартну точку монтування файлової системи. service Визначає демона, який може бути запущений, зупинений, перезапущений, перезавантажений і т. д. Це традиційні види діяльності для механізму запуску SysVinit, тому механізм systemd здатний автоматично проаналізувати LSB-коментарі в скриптах запуску SysVinit (ця тема розглянута в розділі Розуміння і використання SysVinit ) І використовувати цю інформацію відповідним чином. socket Являє файлову систему або мережевий сокет стандартного типу, такий як AF_INET або AF_UNIX, що дозволяє входять з'єднанням з такими сокетами ініціювати запуск асоційованих сервісів. target Визначає логічний елемент, що використовується групою інших елементів, які є концептуально пов'язаними. Наприклад, механізм systemd використовує елемент graphical.target для збору всіх додатків, які повинні бути запущені на системі з графічною консоллю після того, як графічний пристрій стане доступним.

Файли сервісу, асоційовані з типами елементів, які підтримує механізм systemd, зазвичай знаходяться в підкаталогах / etc / systemd. В лістінгу 4 показаний приклад конфігураційного файлу сервісу systemd.

Лістинг 4. Приклад конфігураційного файлу сервісу systemd

[Unit] Description = System Logging Service [Service] EnvironmentFile = - / etc / sysconfig / rsyslog ExecStart = / sbin / rsyslogd -n $ SYSLOGD_OPTIONS Sockets = syslog.socket StandardOutput = null [Install] WantedBy = multi-user.target Alias ​​= syslog.service

Цей файл є визначення елемента для журналу syslog з rsyslog.service системи Fedora 17; він знаходиться в каталозі /etc/systemd/system/multi-user.target.wants. Різні секції цього файлу містять опис елемента, з яким він асоційований, вказують, як запустити сервіс і які ресурси він використовує, а також вказують обставини, при яких здійснюється виклик цього елемента - в даному випадку виклик здійснюється, коли мета запуску системи має вигляд multi- user.target.

Механізм запуску systemd використовує команду systemctl для запуску, зупинки та перевірки стану елементів різних типів з командного рядка. Команда systemadm надає графічний інтерфейс, який надає аналогічні можливості, проте він не встановлюється за умовчанням. Щоб додати його, необхідно встановити пакет systemd-gtk.

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

Моніторинг запуску системи і виконання скрипта

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

• Які команди або скрипти ініціалізації виконувалися в процесі запуску системи?
• У якому порядку виконувалися ці команди або скрипти?
• Скільки часу потрібно кожній команді або кожному скрипту?

Якщо ви всього лише додаєте один скрипт до процесу запуску системи, то на першому етапі вас цікавить, виповнюється цей скрипт насправді і якщо виконується, то в якій точці. Простий спосіб отримати цю інформацію - викликати команду / usr / bin / logger з вашого скрипта. Команда logger записує повідомлення в системний журнал із заданим пріоритетом. Наприклад, наступна команда записує повідомлення New script executed з числовим пріоритетом, відповідним повідомленням типу alert, яке завжди необхідно журналіровать.

/ Usr / bin / logger -p 1 "New script executed"

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

Спочатку утиліта Bootchart була написана як скрипт оболонки, проте її остання версія, Bootchart 2, була переписана на мові C, щоб підвищити продуктивність і зменшити вплив самої утиліти на що збираються нею дані. Щоб використовувати останню версію Bootchart 2, завантажте вихідний код для поточної версії, виконайте збірку і установку додатка, а потім інтегрувати його в команди початкового завантажувача (bootloader), який ви використовуєте для завантаження своєї системи. Для побудови та встановлення Bootchart 2 на вашій системі повинні бути встановлені наступні компоненти: система контролю вихідного коду git, інструмент make для компіляції програми та C-компілятор gcc. Після цього ви зможете виконувати такі дії.

1. Використовувати команду git з метою клонування репозитария вихідного коду для Bootchart 2.

   git clone https://github.com/mmeeks/bootchart

2. Змінити каталог на каталог bootchart, який був створений на попередньому кроці, і виконати команду make для компіляції різних фрагментів Bootchart 2.
3. Від імені користувача root або за допомогою команди sudo виконати команду make install для установки різних додатків Bootchart 2 і їх документації в місцях розташування за замовчуванням.

4. Додати наступний фрагмент в кінець запису для ядра в файлі конфігурації використовуваного вами початкового завантажувача.

   initcall_debug printk.time = y quiet init = / sbin / bootchartd

   Якщо ви використовуєте початковий завантажувач GRUB, то, ймовірно, ви додасте попередній текстовий фрагмент до stanza-записи початкового завантаження в файлі /boot/grub/menu.lst. Якщо ви використовуєте GRUB2, то, ймовірно, ви додасте попередній текстовий фрагмент до stanza-записи початкового завантаження в файлі /boot/grub/grub.conf. Якщо конфігураційний файл GRUB у вашій системі був створений автоматично за допомогою команд, подібних grub-mkconfig або grub2-mkconfig, вам слід додати попередній текстовий фрагмент до опцій за замовчуванням для початкового завантаження ядра, які визначені в файлі / etc / default / grub, а потім заново згенерувати конфігураційний файл свого фактичного завантажувача.

При наступному перезавантаженні вашої системи утиліта Bootchart 2 збере дані про кожну стадію процесу початкового завантаження і згенерує графічну зведення цих даних в форматі PNG. Зведені дані зберігаються у файлі /var/log/bootchart.tgz, а відповідне їм графічне представлення зберігається в файлі /var/log/bootchart.png. на Мал. 1 показаний фрагмент графічного зображення процесу початкового завантаження.

Малюнок 1. Фрагмент графічного представлення початкового завантаження, отриманий за допомогою утиліти Bootchart

Верхня частина отриманого за допомогою Bootchart 2 графічного представлення процесів початкового завантаження являє собою зведену інформацію про досліджувану систему, включаючи загальну тривалість процесу запуску. Середня частина - це графічне представлення всіх процесів запуску ( Мал. 1 є фрагментом цієї вистави). Два розділи в нижній частині демонструють сукупне споживання процесами процесорних ресурсів і ресурсів вводу / виводу.

При кожному перезавантаженні системи всі попередні файли з зазначеними іменами перезаписувати. Якщо ви експериментуєте зі способами зміни порядку виконання різних скриптів в процесі запуску системи і / або намагаєтеся оптимізувати вміст цих скриптів, корисно буде зберегти зведені дані утиліти Bootchart 2 для декількох початкових завантажень системи для спрощення порівняння результатів.

У файлі конфігурації Bootchart 2 (/etc/bootchartd.conf) є змінна CUSTOM_POST_CMD. Ця змінна дозволяє вказати повний маршрут до скрипта або до іншого додатку, виконуваним після того, як утиліта Bootchart 2 створить свої дані і асоційовані з ними графічні файли. код в лістингу 5 являє собою приклад скрипта, який можна використовувати для перейменування вихідних файлів з присвоєнням їм імен виду YYYY-MM-DD-HH-MM-HOSTNAME і збереженням цих файлів в каталозі / var / log / bootchart.

Лістинг 5. Приклад скрипта для присвоєння нових унікальних імен вихідним файлів Bootchart

#! / Bin / bash source /etc/bootchartd.conf HOST = $ (hostname -s) if [! -d $ (dirname $ BOOTLOG_DEST) "/ bootchart"]; then mkdir $ (dirname $ BOOTLOG_DEST) "/ bootchart" fi DATE = $ (date +% Y-% m-% d-% H-% M) filebase = "$ DATE- $ HOST" mv $ BOOTLOG_DEST $ (dirname $ BOOTLOG_DEST) "/ bootchart /" $ {filebase} ". tgz" if [ "x $ AUTO_RENDER" = "xyes"]; then mv $ {AUTO_RENDER_DIR} / bootchart. $ {AUTO_RENDER_FORMAT} \ $ (dirname $ BOOTLOG_DEST) "/ bootchart /" $ {filebase} "." $ {AUTO_RENDER_FORMAT} fi

Утиліта Bootchart 2 працює з усіма механізмами запуску Linux-систем, описаними в цій статті, і надає вельми корисну інформацію про те, скільки часу, процесорних ресурсів і ресурсів вводу / виводу споживається на кожному кроці послідовності запуску системи. Це допомагає виявити в послідовності запуску фрагменти, які має сенс оптимізувати для скорочення часу запуску системи.

Висновок

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

Ресурси для скачування

Схожі тими

• Оригінал статті: Customizing and monitoring Linux system startup .
• Подробиці процесу завантаження Linux, developerWorks, май 2006 р Прекрасне введення в основні стадії завантаження Linux-системи.
• Boot Linux faster (Прискорення завантаження Linux), developerWorks, вересень 2003 г. Відмінний огляд процесу запуску системи SysVinit, що містить кілька хороших пропозицій з аналізу і підвищення продуктивності Linux-систем, що використовують цей механізм запуску.
• LSB - це стандарт, розроблений декількома авторами інших збірок Linux для гарантування сумісності скриптів SysVinit в різних дистрибутивах Linux.
• Init Script Actions (Дії скрипта Init Script) - в цьому документі описуються стандартні команди, які повинні бути доступні в скриптах SysVinit, сумісних зі стандартом LSB версії 4.1 (діюча версія на момент написання цієї статті).
• Comment Conventions for Init Scripts (Угоди з коментування сценарій запуску) - в цьому документі описуються коментарі, які повинні бути присутніми в скриптах SysVinit, сумісних зі стандартом LSB версії 4.1, з метою позначення залежностей і рівнів runlevel, з яким повинен бути асоційований сумісний скрипт ініціалізації.
• Parallelize applications for faster Linux booting (Параллелизация додатків з метою прискорення початкового завантаження Linux), developerWorks, березень 2007 р У цій статті розглядаються механізми запуску (initng і upstart), а також використання первісної версії Upstart для моніторингу та візуалізації процесу запуску Linux.
• Upstart Intro, Cookbook and Best Practises - офіційна документація Ubuntu по застосуванню Upstart, в т. Ч. По створенню conf-файлів Upstart.
• Rethinking Pid 1 , Квітень, 2010 р Прекрасне введення в цілі і реалізацію механізму systemd, написане його початковим розробником (Леннартом Путтерінгом).
• Why systemd? , Квітень, 2010 р У цьому документі порівнюються можливості SysVinit, Upstart і systemd. Читачі повинні мати на увазі, що цей документ був написаний початковим розробником systemd (Леннартом Путтерінгом); відповідно, обрані ним для порівняння характеристики в більш вигідному світлі представляють можливості systemd.
• systemd for Administrators, Part 1 , Серпень 2010 р Перша частина циклу навчальних посібників з systemd для системних адміністраторів (автор - Леннартом Путтерінгом).
• The systemd Fallacy - альтернативний - і вельми емоційний - погляд на systemd.
• Bootchart 2 Project Summary - розділ на ресурсі Ohloh зі зведеною інформацією по цілям останньої версії Bootchart і реалізованим в ній змін.
• свіжу версію Bootchart 2 можна завантажити зі сторінки цього проекту в репозитарії GitHub.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів