Součástí práce správce systému je analyzovat výkon systémů a hledat a řešit problémy, které způsobují slabý výkon a dlouhé doby spouštění. Systémoví správci také potřebují zkontrolovat další aspekty konfigurace a použití systemd.
Systém systemd init poskytuje systemd-analyze nástroj, který může pomoci odhalit problémy s výkonem a další důležité systémové informace. V předchozím článku Analýza systémového kalendáře a časových rozpětí , použil jsem systemd-analyze analyzovat časová razítka a časová rozpětí v časovačích systemd, ale tento nástroj má mnoho dalších využití, z nichž některá prozkoumám v tomto článku.
Přehled spouštění
Spouštěcí sekvence Linuxu je dobrým místem, kde začít zkoumat, protože mnoho systemd-analyze funkce nástroje jsou zaměřeny na spuštění. Nejprve je však důležité pochopit rozdíl mezi spouštěním a spouštěním. Zaváděcí sekvence začíná samočinným testem při zapnutí BIOSu (POST) a končí, když je dokončeno načítání jádra a přebírá kontrolu nad hostitelským systémem, což je začátek spouštění a bod, kdy začíná žurnál systemd.
Ve druhém článku této série Porozumění systemd při spuštění v systému Linux , rozebírám spouštění trochu podrobněji s ohledem na to, co se děje a v jakém pořadí. V tomto článku chci prozkoumat spouštěcí posloupnost, abych se podíval na množství času, které trvá spouštění a které úlohy zaberou nejvíce času.
Výsledky, které ukážu níže, jsou z mé primární pracovní stanice, což je mnohem zajímavější než výsledky virtuálního stroje. Tato pracovní stanice se skládá ze základní desky ASUS TUF X299 Mark 2, CPU Intel i9-7960X s 16 jádry a 32 CPU (vlákny) a 64GB RAM. Některé z níže uvedených příkazů může spouštět uživatel bez oprávnění root, ale v tomto článku použiji root, abych nemusel přepínat mezi uživateli.
Existuje několik možností, jak prozkoumat spouštěcí sekvenci. Nejjednodušší forma systemd-analyze příkaz zobrazí přehled množství času stráveného v každé z hlavních částí spouštění, spouštění jádra, načítání a spouštění initrd (tj. počáteční ramdisk, dočasný systémový obraz, který se používá k inicializaci některého hardwaru a připojení / [root] filesystem) a uživatelský prostor (kde jsou načteny všechny programy a démony potřebné k uvedení hostitele do použitelného stavu). Pokud příkazu není předán žádný dílčí příkaz, systemd-analyze time je implicitní:
[root@david ~]$ systemd-analyze
Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233s
graphical.target reached after 10.071s in userspace
[root@david ~]#
Nejpozoruhodnější údaje v tomto výstupu je množství času stráveného ve firmwaru (BIOS):téměř 54 sekund. To je mimořádně dlouhá doba a žádnému z mých jiných fyzických systémů netrvá tak dlouho, než se dostane přes BIOS.
Můj notebook System76 Oryx Pro stráví v BIOSu pouze 8,506 sekund a všechny mé doma vyrobené systémy zaberou o něco méně než 10 sekund. Po několika online hledáních jsem zjistil, že tato základní deska je známá svou neúměrně dlouhou dobou spouštění systému BIOS. Moje základní deska nikdy „jen bootuje“. Vždy se to zasekne a musím provést cyklus vypnutí/zapnutí a pak se BIOS spustí s chybou a musím stisknout F1 pro vstup do konfigurace BIOSu, odkud mohu vybrat spouštěcí jednotku a dokončit spouštění. Odtud pochází čas navíc.
Ne všichni hostitelé zobrazují data firmwaru. Mé nevědecké experimenty mě vedly k přesvědčení, že tato data se zobrazují pouze pro procesory Intel generace 9 nebo vyšší. Ale to může být nesprávné.
Tento přehled procesu spouštění spouštění je zajímavý a poskytuje dobré (i když omezené) informace, ale o spouštění je k dispozici mnohem více informací, jak popíšu níže.
Přiřazení viny
Můžete použít systemd-analyze blame zjistit, které systémové jednotky inicializace zaberou nejvíce času. Výsledky jsou zobrazeny v pořadí podle doby, kterou zabere inicializace, od nejvíce po nejméně:
[root@david ~]$ systemd-analyze blame
5.417s NetworkManager-wait-online.service
3.423s dracut-initqueue.service
2.715s systemd-udev-settle.service
2.519s fstrim.service
1.275s udisks2.service
1.271s smartd.service
996ms upower.service
637ms lvm2-monitor.service
533ms lvm2-pvscan@8:17.service
520ms dmraid-activation.service
460ms vboxdrv.service
396ms initrd-switch-root.service
<SNIP – removed lots of entries with increasingly small times>
Vzhledem k tomu, že mnoho z těchto služeb začíná paralelně, může být celkový součet výrazně vyšší, než je součet daný systemd-analyze time pro vše po BIOSu. To vše jsou malá čísla, takže zde nemohu najít žádné významné úspory.
Data z tohoto příkazu mohou poskytnout informace o tom, které služby byste mohli zvážit pro zlepšení doby spouštění. Služby, které se nepoužívají, lze zakázat. Zdá se, že neexistuje žádná jednotlivá služba, která by během této spouštěcí sekvence trvala příliš dlouho. Pro každé spuštění a spuštění můžete vidět různé výsledky.
Kritické řetězce
Stejně jako kritická cesta v projektovém řízení, kritický řetězec ukazuje časově kritický řetězec událostí, které se odehrávají během spouštění. Toto jsou systémové jednotky, na které se chcete podívat, pokud je spouštění pomalé, protože to jsou ty, které by způsobily zpoždění. Tento nástroj nezobrazuje všechny jednotky, které začínají, pouze jednotky v tomto kritickém řetězci událostí:
[root@david ~]# 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 @10.071s
└─lxdm.service @10.071s
└─plymouth-quit.service @10.047s +22ms
└─systemd-user-sessions.service @10.031s +7ms
└─remote-fs.target @10.026s
└─remote-fs-pre.target @10.025s
└─nfs-client.target @4.636s
└─gssproxy.service @4.607s +28ms
└─network.target @4.604s
└─NetworkManager.service @4.383s +219ms
└─dbus-broker.service @4.434s +136ms
└─dbus.socket @4.369s
└─sysinit.target @4.354s
└─systemd-update-utmp.service @4.345s +9ms
└─auditd.service @4.301s +42ms
└─systemd-tmpfiles-setup.service @4.254s +42ms
└─import-state.service @4.233s +19ms
└─local-fs.target @4.229s
└─Virtual.mount @4.019s +209ms
└─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s +274ms
└─local-fs-pre.target @3.726s
└─lvm2-monitor.service @356ms +637ms
└─dm-event.socket @319ms
└─-.mount
└─system.slice
└─-.slice
[root@david ~]#
Čísla předcházená znakem @ zobrazit absolutní počet sekund od spuštění, kdy se jednotka stane aktivní. Čísla, před kterými je + zobrazit dobu, za kterou se jednotka spustí.
Stav systému
Někdy je potřeba zjistit aktuální stav systému. systemd-analyze dump příkaz vypíše masivní množství dat o aktuálním stavu systému. Začíná seznamem primárních časových značek spouštění, seznamem každé systémové jednotky a úplným popisem stavu každé z nich:
[root@david ~]# systemd-analyze dump
Timestamp firmware: 1min 7.983523s
Timestamp loader: 3.872325s
Timestamp kernel: Wed 2020-08-26 12:33:35 EDT
Timestamp initrd: Wed 2020-08-26 12:33:38 EDT
Timestamp userspace: Wed 2020-08-26 12:33:42 EDT
Timestamp finish: Wed 2020-08-26 16:33:56 EDT
Timestamp security-start: Wed 2020-08-26 12:33:42 EDT
Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT
Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT
Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT
-> Unit system.slice:
Description: System Slice
Instance: n/a
Unit Load State: loaded
Unit Active State: active
State Change Timestamp: Wed 2020-08-26 12:33:38 EDT
Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Exit Timestamp: n/a
Inactive Enter Timestamp: n/a
May GC: no
<SNIP – Deleted a bazillion lines of output>
Na mé hlavní pracovní stanici tento příkaz vygeneroval proud 49 680 řádků a přibližně 1,66 MB. Tento příkaz je velmi rychlý, takže nemusíte čekat na výsledky.
Další zdroje pro Linux
- Cheat pro příkazy Linuxu
- Cheat sheet pro pokročilé příkazy systému Linux
- Bezplatný online kurz:Technický přehled RHEL
- Síťový cheat pro Linux
- Cheat sheet SELinux
- Cheat pro běžné příkazy pro Linux
- Co jsou kontejnery systému Linux?
- Naše nejnovější články o Linuxu
Líbí se mi množství detailů poskytovaných pro různá připojená zařízení, jako je úložiště. Každá jednotka systemd má sekci s podrobnostmi, jako jsou režimy pro různá běhová prostředí, mezipaměť a adresáře protokolů, příkazový řádek použitý ke spuštění jednotky, ID procesu (PID), časové razítko spuštění a také limity paměti a souborů.
Manuál pro systemd-analyze zobrazuje systemd-analyze --user dump volba, která je určena k zobrazení informací o vnitřním stavu správce uživatelů. To se mi nedaří a vyhledávání na internetu naznačuje, že s tím může být problém. V systemd --user instance se používají ke správě a řízení zdrojů pro hierarchii procesů patřících každému uživateli. Procesy pro každého uživatele jsou součástí kontrolní skupiny, které se budu věnovat v budoucím článku.
Analytické grafy
Pro většinu špičatých šéfů (PHB) a mnoho dobrých manažerů jsou hezké grafy čitelnější a srozumitelnější než textová data o výkonu systému, která obvykle preferuji. Někdy se ale i mně líbí dobrý graf a systemd-analyze poskytuje možnost zobrazit data spouštění/spouštění v grafu vektorové grafiky SVG.
Následující příkaz vygeneruje soubor vektorové grafiky, který zobrazuje události, ke kterým dochází během spouštění a spouštění. Vygenerování tohoto souboru trvá jen několik sekund:
[root@david ~]# systemd-analyze plot > /tmp/bootup.svgTento příkaz vytvoří SVG, což je textový soubor, který definuje řadu grafických vektorů, které aplikace, včetně Image Viewer, Ristretto, Okular, Eye of Mate, LibreOffice Draw a dalších, používají ke generování grafu. Tyto aplikace zpracovávají soubory SVG a vytvářejí obrázek.
K vykreslení grafu jsem použil LibreOffice Draw. Graf je obrovský a je potřeba jej značně přiblížit, abyste rozeznali jakýkoli detail. Zde je malá část:
Spouštěcí sekvence je vlevo od nuly (0) na časové ose v grafu a spouštěcí sekvence je vpravo od nuly. Tato malá část ukazuje jádro initrd a procesy initrd začalo.
Tento graf na první pohled ukazuje, co kdy začalo, jak dlouho spuštění trvalo a hlavní závislosti. Kritická cesta je zvýrazněna červeně.
Dalším příkazem, který generuje grafický výstup, je systemd-analyze plot . Generuje textové popisy grafů závislostí ve formátu DOT. Výsledný datový tok je pak veden přes dot utility, která je součástí rodiny programů, které lze použít ke generování vektorových grafických souborů z různých typů dat. Tyto soubory SVG lze také zpracovat výše uvedenými nástroji.
Nejprve vygenerujte soubor. Na mé primární pracovní stanici to trvalo téměř devět minut:
[root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg
Color legend: black = Requires
dark blue = Requisite
dark grey = Wants
red = Conflicts
green = After
real 8m37.544s
user 8m35.375s
sys 0m0.070s
[root@david ~]#
Nebudu zde reprodukovat výstup, protože výsledný graf je do značné míry špagetový. Ale měli byste to zkusit a podívat se na výsledek, abyste viděli, co tím myslím.
Podmíněné
Jedna ze zajímavějších, ale poněkud obecných funkcí, kterou jsem objevil při čtení systemd-analyze(1) manuálová stránka je condition dílčí příkaz. (Ano – čtu manuálové stránky a je úžasné, co jsem se tímto způsobem naučil!) Tato condition dílčí příkaz lze použít k testování podmínek a tvrzení, která lze použít v souborech jednotek systemd.
Lze jej také použít ve skriptech k vyhodnocení jedné nebo více podmínek – vrátí nulu (0), pokud jsou splněny všechny, nebo jedničku (1), pokud některá podmínka splněna není. V obou případech také chrlí text o svých zjištěních.
Níže uvedený příklad z manuálové stránky je trochu složitý. Testuje verzi jádra mezi 4.0 a 5.1, že hostitel běží na střídavý proud, že architektura systému je jiná než ARM a že adresář /etc/os-release existuje. Přidal jsem echo $? příkaz k vytištění návratového kódu.
[root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release' ; \
echo $?
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
0
[root@david ~]#
Seznam podmínek a tvrzení začíná kolem řádku 600 na systemd.unit(5) manuálová stránka.
Výpis konfiguračních souborů
systemd-analyze nástroj poskytuje způsob, jak odeslat obsah různých konfiguračních souborů do STDOUT , jak je znázorněno zde. Základní adresář je /etc/ :
[root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service
# /etc/systemd/system/display-manager.service
[Unit]
Description=LXDM (Lightweight X11 Display Manager)
#Documentation=man:lxdm(8)
[email protected]
After=systemd-user-sessions.service [email protected] plymouth-quit.service livesys-late.service
#Conflicts=plymouth-quit.service
[Service]
ExecStart=/usr/sbin/lxdm
Restart=always
IgnoreSIGPIPE=no
#BusName=org.freedesktop.lxdm
[Install]
Alias=display-manager.service
[root@david ~]#
Toto je hodně psaní, které nedělá nic jiného než standardní cat příkaz dělá. Další příkaz považuji za trochu užitečný. Může vyhledávat soubory se zadaným vzorem ve standardních umístěních systemd:
[root@david ~]# systemctl cat backup*
# /etc/systemd/system/backup.timer
# This timer unit runs the local backup program
# (C) David Both
# Licensed under GPL V2
#
[Unit]
Description=Perform system backups
Requires=backup.service
[Timer]
Unit=backup.service
OnCalendar=*-*-* 00:15:30
[Install]
WantedBy=timers.target
# /etc/systemd/system/backup.service
# This service unit runs the rsbu backup program
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Backup services using rsbu
Wants=backup.timer
[Service]
Type=oneshot
Environment="HOME=/root"
ExecStart=/usr/local/bin/rsbu -bvd1
ExecStart=/usr/local/bin/rsbu -buvd2
[Install]
WantedBy=multi-user.target
[root@david ~]#
Oba tyto příkazy uvozují obsah každého souboru řádkem s komentářem obsahujícím úplnou cestu a název souboru.
Ověření souboru jednotky
Po vytvoření nového souboru jednotek může být užitečné ověřit, zda je jeho syntaxe správná. To je to, co verify dílčí příkaz dělá. Může vypsat direktivy, které jsou napsány nesprávně, a vyvolat chybějící servisní jednotky:
[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.serviceV souladu s filozofií Unix/Linux, že „ticho je zlato“, nedostatek výstupních zpráv znamená, že v naskenovaném souboru nejsou žádné chyby.
Zabezpečení
security dílčí příkaz kontroluje úroveň zabezpečení zadaných služeb. Funguje pouze na servisních jednotkách a ne na jiných typech souborů jednotek:
[root@david ~]# systemd-analyze security display-manager
NAME DESCRIPTION >
✗ PrivateNetwork= Service has access to the host's network >
✗ User=/DynamicUser= Service runs as root user >
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities >
✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges >
✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities >
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets >
✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces >
✗ RestrictAddressFamilies=~… Service may allocate exotic sockets >
✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres>
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks >
✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges >
✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules
<SNIP>
✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() >
✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system >
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets >
→ Overall exposure level for backup.service: 9.6 UNSAFE ?
lines 34-81/81 (END)
Ano, emotikon je součástí výstupu. Ale samozřejmě mnoho služeb potřebuje téměř úplný přístup ke všemu, aby mohly vykonávat svou práci. Spustil jsem tento program proti několika službám, včetně mé vlastní zálohovací služby; výsledky se mohou lišit, ale konečný výsledek se zdá být většinou stejný.
Tento nástroj by byl velmi užitečný pro kontrolu a opravu jednotek služeb v uživatelském prostoru v prostředích kritických z hlediska bezpečnosti. Myslím, že pro většinu z nás toho nemá moc co nabídnout.
Poslední myšlenky
Tento výkonný nástroj nabízí několik zajímavých a úžasně užitečných možností. Mnoho z toho, co tento článek zkoumá, se týká použití systemd-analyze poskytnout přehled o spouštěcím výkonu Linuxu pomocí systemd. Může také analyzovat další aspekty systemd.
Některé z těchto nástrojů mají omezené použití a na několik bychom měli úplně zapomenout. Většinu však lze s dobrým efektem použít při řešení problémů se spouštěním a dalšími systémovými funkcemi.
Zdroje
Na internetu je k dispozici velké množství informací o systemd, ale mnohé jsou stručné, tupé nebo dokonce zavádějící. Kromě zdrojů uvedených v tomto článku nabízejí následující webové stránky podrobnější a spolehlivější informace o spouštění systemd. Tento seznam se rozrostl od doby, kdy jsem začal s touto sérií článků, aby odrážel výzkum, který jsem provedl.
- Manuálová stránka systemd.unit(5) obsahuje pěkný seznam sekcí souborů jednotek a jejich konfiguračních možností spolu se stručným popisem každé z nich.
- Projekt Fedora má dobrého praktického průvodce systemd. Obsahuje téměř vše, co potřebujete vědět, abyste mohli nakonfigurovat, spravovat a udržovat počítač Fedora pomocí systemd.
- Projekt Fedora má také dobrý cheat sheet, který křížově odkazuje na staré příkazy SystemV se srovnatelnými příkazy systemd.
- Dokumentace Red Hat obsahuje dobrý popis struktury souborů Unit a další důležité informace.
- Podrobné technické informace o systemd a důvodech pro jeho vytvoření naleznete v popisu systemd na Freedesktop.org.
- Pokročilejší systémové informace a tipy nabízí stránka Linux.com „More systemd fun“.
Existuje také řada hluboce technických článků pro správce systému Linux od Lennarta Poetteringa, návrháře a primárního vývojáře systemd. Tyto články byly napsány mezi dubnem 2010 a zářím 2011, ale nyní jsou stejně aktuální jako tehdy. Většina všeho dobrého, co bylo napsáno o systemd a jeho ekosystému, je založeno na těchto dokumentech.
- Přehodnocení PID 1
- systemd pro administrátory, část I
- systemd pro administrátory, část II
- systemd pro administrátory, část III
- systemd pro administrátory, část IV
- systemd pro administrátory, část V
- systemd pro administrátory, část VI
- systemd pro administrátory, část VII
- systemd pro administrátory, část VIII
- systemd pro administrátory, část IX
- systemd pro administrátory, část X
- systemd pro administrátory, část XI