systemd-analyze – rendszerindulás sebessége

A systemd alapokat ismerjük, és már azt is tudjuk, hogy egy jó naplózási megoldást is tartalmaz. A mai részben egy érdekes, de nem minden nap használt ismerhetünk meg. Ebben a cikkben bemutatom, hogyan lehet elemezni a Linux rendszer indítási teljesítményét, annak statisztikáját a systemd-analyze segítségével.
Miért? Általában nem törődünk az indítási folyamat gyorsaságával, annak mérésével. Adottnak vesszük, és ha nem túl lassú, akkor eszünkbe sem jut vizsgálni. Ha pedig rákérdeznek, hogy mennyi is az indítási idő, akkor csak saccolunk, és nem konkrét számot mondunk.
Bár alapesetben a mai gépeken nem is érdekes az indulási idő, de azért egyszer érdemes megnézni azt a módot, ahogy ezt számszerűsíthetjük. Ha pedig már nézegetjük, akkor gondoljuk át, hogy lehetne lehetne gyorsabb?

Systemd-analyze – alapok

A rendszer indítási idejének áttekintése érdekében argumentumok nélkül futtathatjuk a

systemd-analyze

parancsot. Felsorolja az egyes szolgáltatások indításának időtartamát, ideértve a kernel, az initrd és a felhasználói terület indításakor eltöltött időt. Nálam a kimenet:

laci:~/ $ systemd-analyze [10:50:13]
Startup finished in 20.233s (firmware) + 5.450s (loader) + 1.467s (kernel) + 2.484s (userspace) = 29.636s
graphical.target reached after 1.086s in userspace

30secundum… No én ezen nem fogok faragni, hogy 29 legyen 🙂 Ami miatt fontos egy ilyen érték az összehasonlítás. Amikor lassúnak tartod a boot folyamatot, megnézheted a valódi lassulást. Így nem keresel hibát, ha csak türelmetlenebb vagy, vagy sietsz és ezért érzed lassúnak az indulást.

A részletes értékek lekérdezése

Alapesetben nincs sok teendőnk, mert a jól összerakott Linux rendszer hamar elindul. De mi van, ha kicsit állogatni szeretnéd a gyorsaságot? Érdemes megnézni mi indul és milyen lassan. Itt is el kell mondanom, amit az előző részben: ez egy rendszerhez nagyon közeli téma, így amihez nem értesz azt nem állogatod! Bár szíved joga, hogy mit teszel, és nem túl nehéz visszaállítani egy elrontott beállítás, jellemzően leállított szolgáltatást, de jobb ha nem ezzel megy el az idő.

systemd-analyze blame

Ezután már egy hosszabb listát kapunk.

11.334s updatedb.service
6.147s NetworkManager-wait-online.service
1.381s lightdm.service
1.172s udisks2.service
819ms man-db.service
726ms systemd-logind.service
490ms upower.service
436ms lvm2-monitor.service
329ms systemd-random-seed.service
325ms dev-nvme0n1p2.device
213ms home-laci-Let\xc3\xb6lt\xc3\xa9sek.mount
197ms systemd-journald.service
196ms systemd-udevd.service
189ms swapfile.swap
179ms systemd-tmpfiles-clean.service
112ms user@1000.service
104ms org.cups.cupsd.service

Akinek valami nem kell, vagy lassúnak tartja az indulást és valamit letiltana annak nincs más teendője, csak kiszedi a nem kívánt szolgáltatását a systemd rendszernek.
Ha gyorsítani akarsz, és értesz is hozzá, akkor a hosszabb idő alatt induló systemd szolgáltatást akár cron-ból is – vagy manuálisan – indíthatod, ha már felállt a rendszered. Bár nem biztos, hogy érdemes vele foglalkozni, de a lehetőség a tied.

Hogyan kezdjünk hozzá, ha valamit állítani akarunk?

Bár a systemd általában normálisan nevezi el a szolgáltatásokat, így a beazonosítás nem okozhat gondot. De menjünk biztosra, és kérdezzük le a leghosszabb ideig induló szolgáltatást: updatedb.service-t. A módját mát ismerjük:

systemctl status updatedb

● updatedb.service – Update locate database
Loaded: loaded (/usr/lib/systemd/system/updatedb.service; static)
Active: inactive (dead) since Mon 2020-10-26 00:00:12 CET; 7h ago
TriggeredBy: ● updatedb.timer
Process: 88085 ExecStart=/usr/bin/updatedb (code=exited, status=0/SUCCESS)
Main PID: 88085 (code=exited, status=0/SUCCESS)

okt 26 00:00:01 laci systemd[1]: Starting Update locate database…
okt 26 00:00:12 laci systemd[1]: updatedb.service: Succeeded.
okt 26 00:00:12 laci systemd[1]: Finished Update locate database.

Ok. Amint remélem mindenki sejtette az locate adatbázist, fájlok helyeinek az adatbázisát frissíti. Akinek bármiféle egyéb infó kell a locate parancsról, akkor a google nagyon sok jó leírást ad. Ha egyáltalán nem ismered, és soknak tartod a 11 másodpercet, akkor mindenképp olvass utána.
A listázás ad egy TriggeredBy: ● updatedb.timer sort is. Bár még nem volt szó róla, de a systemd alkalmas parancsok, feladatok ütemezésére is. Ezeknek a kiterjesztése a timer, ami szintén bizonyítja, hogy az elnevezések elég jól tükrözik a feladatot.

Most nézzük meg mi is ez?

systemctl status updatedb.timer

● updatedb.timer – Daily locate database update
Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
Active: active (waiting) since Sun 2020-10-25 14:35:24 CET; 17h ago
Trigger: Tue 2020-10-27 00:00:00 CET; 16h left
Triggers: ● updatedb.service

okt 25 14:35:24 laci systemd[1]: Started Daily locate database update.

Sokkal nem lettünk okosabbak, ezt sejtettük. Így nézzünk bele a /usr/lib/systemd/system/updatedb.timer fájlba. Nem kell odanavigálni, most elég a cat is:

cat /usr/lib/systemd/system/updatedb.timer

[Unit]
Description=Daily locate database update

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

Így már látjuk, hogy viszonylag ritkán fut le, ami azt jelezheti nekünk, hogy nem feltétlen kell induláskor lefuttatni. Így ha a rendszerindítás után indulna el, az sem lenne nagy hátrány. Én nem nyúltam hozzá, csak elvben jártuk körbe a lehetőséget! Egy alapoktól felépített rendszeren nem sok igazítani való van, hiszen alap Arch-ra csak a minimum kerül fel, de egy „felhasználóbarátabb” rendszernél már érdemes körbenézni, mert a kényelem miatt követhetik az „induljon el minden, ami esetleg kellhet” elvet is, és sok, neked felesleges szolgáltatást indítanak.

Ha mindezt grafikusan is látni akarod, akkor a

systemd-analyze plot > boot_analysis.svg

paranccsal egy svg képfájlt is készíthetsz, majd azt vizuálisan is elemezheted.

A man systemd-analyze ennél sokkal többet is felsorol, de amit illő tudni a fenti két parancs.

A mai részben egy érdekes, bár nem napi használatra szánt systemd lehetőséget néztünk meg.

Related Posts