Systemd-analyze

Na kraju godine pozabavit ćemo se jednim od alata koje donosi systemd, programom za analizu brzine pokretanja Linuxa. Opsjednuti smo brzinom, vrijeme je novac, korisnici ne žele čekati računalo, bolje da računalo čeka njih! Procesori su višejezgreni, sa "nitima", prilagođeni za paralelno izvršavanje, rade na sve većim taktovima - sve zato da se dobije na brzini. Systemd nastoji iskoristiti te mogućnosti i ubrzati podizanje OS-a.

Alat se zove systemd-analyze.

$ systemd-analyze time 
Startup finished in 3.614s (kernel) + 7.447s (userspace) = 11.062s

Primjer je s notebooka na kojem je Ubuntu s X-ima. Vrijeme je podijeljeno na dva razdoblja: vrijeme potrebno kernelu i vrijeme utrošeno da se sve pripremi za rad korisnika. To se vrijeme naziva prostorom: kernelspace i userspace, dokazujući da je Einstein bio pravu. :)

Ako nam se 11 sekundi za podizanje sustava čini presporo :) zanimat će nas koji servis možemo okriviti za usporavanje:

$ systemd-analyze blame
         15.267s apt-daily.service
          5.742s NetworkManager-wait-online.service
          1.393s dev-sda6.device
           276ms systemd-logind.service
           269ms apparmor.service
           244ms accounts-daemon.service
           224ms console-setup.service
           216ms systemd-rfkill.service 
           203ms snapd.service
           191ms irqbalance.service
           189ms upower.service
           183ms ufw.service
           171ms NetworkManager.service
           169ms gdomap.service
           155ms networking.service
           151ms avahi-daemon.service
           149ms grub-common.service
           144ms apport.service
           139ms thermald.service
           131ms ondemand.service
           123ms speech-dispatcher.service
           109ms systemd-udev-trigger.service
       ... 

Najveći "krivac" u ovom primjeru je apt-daily.service. U postavkama je zadano dnevno provjeravanje dostupnost novih verzija paketa. Tu smo postavku za probu isključili, pa ponovili traženje krivca:

$ systemd-analyze blame
          5.549s NetworkManager-wait-online.service
          1.344s dev-sda6.device
           244ms apparmor.service
           240ms systemd-logind.service
      ...

Najveći krivac je nestao s popisa! No dobro, mogli bismo reći da taj proces ionako ne spada u boot. Troši 15 sekundi, a boot se obavi za 11. Osim toga pokreće se tek nakon što proradi mreža. No apt-daily je zgodno poslužio za provjeru funkcionalnosti analize. Sad možemo vratiti dnevni upgrade, ili ga, kao pravi sistemac stare škole, ručno pokretati svako jutro kad dođemo na posao.

Najkorisnija funkcija analize je izrada grafa koji nam zorno prikazuje cijeli proces podizanja operacijskog sustava i servisa (pardon, unita).

$ systemd-analyze plot  > systemdplot.svg

Rezultat analize dobili smo u grafičkom obliku zapisan u datoteku, koju možemo pogledat na primjer u browseru (file:///putanja/systemdplot.svg), ili pomoću programa display koji je dio imagemagic paketa.

$ display systemdplot.svg

Kažu, s pravom, da slika vrijedi više nego 1000 riječi. Sivom bojom označeno je vrijeme koje je utrošeno za pokretanje kernela ili unita, a crvenom vrijeme čekanja da se završi neki prethodni proces bez kojeg se unit ne može pokrenuti. Optimizacijom bi se to vrijeme čekanja možda moglo skratiti.

Graf je zgodan radi još jedne stvari: nazubljen je, lijepo pokazuje kako se uniti pokreću u grupama, odnosno nekoliko ih kreće istovremeno, a nakon nekog vremena pokreće se druga grupa itd. Na ovaj način je cijela procedura mnogo jasnija. Paralelizam ne znači da se sve pokreće odjednom, nego po grupama, uzimajući u obziri međuovisnosti i redoslijede.

Naredni postupak izradit će nam još jedan graf, ali taj nam neće biti jednako koristan. Naime, slika nije baš pregledna, da bi je cijelu vidjeli treba je smanjiti do te mjere da postaje nečitka, ili je projicirati na veliki ekran ili zid. Naredba za izradu ovog grafikona izgleda ovako:

$ systemd-analyze dot | dot -Tsvg > systemddot.svg
   Color legend: black     = Requires
                 dark blue = Requisite
                 dark grey = Wants
                 red       = Conflicts
                 green     = After

Morat ćete pričekati (oko dvije minute ili više) dok se ne pojavi kursor. Nemojte biti nestrpljivi i stiskati Ctrl-C jer onda nećete dobiti cijelu sliku.



Namjeravao sam napraviti upload originalnih .svg datoteka, ali CMS mi to nije dozvolio, pa sam dijelove slika izrezao i pretvorio u png format. Nije problem, sami ćete napraviti slikice za svoje servere.

Analyze prima i neke parametre koji, reklo bi se, ne spadaju u vremenske analize.

Parametar set-log-level služi za to da podesimo razinu logiranja. Koje su razine objasnili smo opisujući konfiguriranje journal daemona (https://sysportal.carnet.hr/node/1770). Podsjetimo se:

0 ili “emerg”
1 ili “alert”
2 ili “crit”
3 ili “err”
4 ili “warning”
5 ili “notice”
6 ili “info”
7 ili “debug”

Svaka viša razina uključuje i sve prethodne.

Najprije provjerimo zadanu razinu logiranja. Po RedHatovoj dokumentaciji, to bi trebalo napraviti ovako:

$ systemd-analyze get-log-level

ali eto problema: Ubuntu verzija ne poznaje taj parametar. Snaći ćemo se drugačije:

$ systemctl -pLogLevel show
LogLevel=info

Za promjenu loglevela trebaju nam admin ovlasti:

$ sudo systemd-analyze set-log-level debug

Promjena zadana na ovaj način je privremena. Ako želimo trajno promijeniti razinu logiranja, treba editirati konfiguracijsku datoteku.

$ visudo /etc/systemd/system.conf
#LogLevel=info
LogLevel=debug

Parametar set-log-target određuje kamo ćemo usmjeriti logove.

$ systemd-analyze set-log-target console

Moguće vrijednosti su console, syslog, kmsg, syslog-or-kmsg, null.

Provjeru bi, opet po dokumentaciji, trebalo obaviti ovako:

$ systemd-analyze get-log-target

Ali ni to ne radi na Ubuntuu. Radi ovako:

$ systemctl -pLogTarget show
LogTarget=journal-or-kmsg

Mogli bi se zapitati zašto bi uopće naredba za analizu boot procesa služila za promjenu razine logiranja, ili za preusmjeravanje logova? To bi trebala obavljati naredba systemctl, zar ne?

Nećemo se upuštati u rasprave, a razlike između dokumentacije i konkretne implementacije, koja se može razlikovati od jedne do druge verzije Linuxa razriješt će nam naredba man, ili parametar --help.

$ systemd-analyze --help

Naredba systemd-analyze napravljena je u prvom redu za developere i paketaše, a sistemcu će poslužiti ukoliko se upusti u optimizaciju i ubrzavanje rada servera. U članku nismo iscrpili sve njezine mogućnosti, ali je ovo sasvim dovoljno da nas potakne na istraživanje i učenje. Usput smo nabasali na neke probleme, razlike u dokumentaciji i implementaciji, ali to ćemo pripisati činjenici da je systemd još u razvoju. Već smo naučili da sada Linux počinje nalikovati na MS Windowse, pa nas više ne uzrujava (recimo) što je narušen osnovni princip po kome alati trebaju raditi samo jednu stvar i biti maksimalno optimizirani za taj posao. No usprkos svemu systemd-analyze se pokazao kao koristan alat, ne samo za optimizaciju nego i za učenje, razumijevanje Linuxa koji ne stoji na mjestu, nego je živ i razvija se.