Čo vám vráti príkaz systemd-analyze? (diskuse)

[PetebLazar]

$ systemd-analyze 
Startup finished in 6.222s (kernel) + 18.942s (userspace) = 25.165s
graphical.target reached after 18.937s in userspace

[qw11]

systemd-analyze

Startup finished in 3.674s (firmware) + 5.427s (loader) + 3.013s (kernel) + 9.739s (userspace) = 21.855s graphical.target reached after 9.728s in userspace

Ubuntu Mate 20.04 sata SSD.

[Blaazen]

Core2Duo, 5400 RPM disk, Plasma

Startup finished in 7.739s (kernel) + 58.068s (userspace) = 1min 5.808s

graphical.target reached after 58.068s in userspace

[Max]

[1][root@max ~]# systemd-analyze
Startup finished in 3.235s (kernel) + 5.979s (userspace) = 9.214s 
graphical.target reached after 5.978s in userspace

Zdar Max

[figliar0]

Startup finished in 4.144s (kernel) + 4.933s (userspace) = 9.078s 
graphical.target reached after 4.741s in userspace

K čomu to?

[GeorgeWH]

Grafy...

[GeorgeWH]

$ systemd-analyze
bash: systemd-analyze: command not found

[z_sk]

Ako root.

[z_sk]

Resp. instaluj balicek systemd-bootchart.

[PetebLazar]

Já bych si spíš tipnul, že jeho OS nepoužívá systemD.

[the.max]

+1

Jsem na tom stejně

[Dejv]

Root neni potreba

[dskola@lenovot420 ~]$ systemd-analyze
Startup finished in 2.029s (kernel) + 6.547s (initrd) + 1min 51.931s (userspace) = 2min 508ms 
graphical.target reached after 1min 51.908s in userspace

Lenovo T420, Core i5, Fedora 31

[AraxoN]

bash: systemd-analyze: command not found

OpenRC forever!

[the.max]

Přesně!!!

[dolik.rce]

Startup finished in 4.681s (kernel) + 6min 22.281s (userspace) = 6min 26.963s 
graphical.target reached after 14.375s in userspace

Vtipné. Bližší průzkum (systemd-analyze plot) ukázal, že to počítá i čas než jsem se vrátil ze záchoda a vyťukal jméno a heslo

[Heron]

LOL. Tak jsem chtěl zamachrovat s:

# systemd-analyze
Startup finished in 3.700s (userspace) = 1d 1h 20min 58.153s

Ale vůbec nevím, co je to za tím rovnítkem. Man mlčí. Uptime to není, ten je mnohem větší.

Je to nspawn kontejner, boot je 3.7s z toho PostgreSQL 3.2s + Apache 486ms (paralelně). Čistej boot bez služeb cca 200ms.

[jejda]

# systemd-analyze
Startup finished in 18.024s (kernel) + 1min 37.876s (userspace) = 1min 55.900s
graphical.target reached after 38.331s in userspace

Mi přijde, že s pomalým 5400rpm diskem je to paralelní spouštění služeb je stejně k ničemu. Opravte mě jestli se pletu.

[Peter Golis]

Rád si pozriem ako sa zobrazí takáto štatistika bez rozdelenia podľa typu disku (Rotačný HDD, SSD, NVMe). Na rýchlosti CPU v tomto prípade až tak nezáleží, ak človek nemá dobre odležaný muzeálny exponát.

CPU G4 7455 1x800MHz, 4200RPM HDD, Debian 10 (Vek: 17 rokov):

Startup finished in 17.874s (kernel) + 2min 2.353s (userspace) = 2min 20.228s
graphical.target reached after 1min 19.786s in userspace

CPU i5-2520M 4x2.50GHz, 5400RPM HDD. Ubuntu 20.04 (Vek: 8 rokov):

Startup finished in 25.015s (kernel) + 1min 18.137s (userspace) = 1min 43.152s
graphical.target reached after 1min 18.105s in userspace

Ten rozdiel času približne zodpovedá pomeru otáčok diskov, len s 5% odchýlkou. Rozsah nainštalovaného SW je približne rovnaký. Ten starší stroj má naozaj rok výroby 2003, a novší je z roku 2012.

[disorder]

som velmi prekvapeny, lebo dlhe roky som mal na debiane otrasny boot time zatialco vsetky ine distribucie sa isli pototo z bootu a po x upgradoch debianu (asi odkedy sa preslo na paralelny systemd). procesor relativne novy i5-6300U CPU @ 2.40GHz, ale aj na tarej 0.5 generacii to ide celkom rychlo (16+19, graphical za 19).

systemd-analyze Startup finished in 4.459s (kernel) + 8.707s (userspace) = 13.167s graphical.target reached after 8.559s in userspace

[AsciiWolf]

$ systemd-analyze
Startup finished in 2.040s (kernel) + 10.155s (initrd) + 23.630s (userspace) = 35.827s 
graphical.target reached after 23.585s in userspace

Fedora 32 na pracovním laptopu s Core i7 a NVMe SSD. Trochu mi to zpomalují různé custom unity.

[jiwopene]

~ systemd-analyze
bash: systemd-analyze: příkaz nenalezen

[MM]

$ systemd-analyze Startup finished in 4.713s (kernel) + 29.734s (userspace) = 34.447s graphical.target reached after 25.709s in userspace

rotační 5400rpm, Haswell-I7@2.3G, archlinux, NB starý 6let

[krab1k]

Startup finished in 2.425s (kernel) + 7.185s (initrd) + 9.313s (userspace) = 18.924s 
graphical.target reached after 9.305s in userspace

Ryzen 3600, Samsung 970 EVO.

[OW]

Startup finished in 17.018s (kernel) + 1min 28.849s (userspace) = 1min 45.867s graphical.target reached after 1min 28.480s in userspace

[User682]

systemd-analyze 
Startup finished in 9.631s (kernel) + 11.966s (userspace) = 21.598s 
graphical.target reached after 8.601s in userspace

Asi spatnej HW ...... AMD 3990X.

[Aleš Kapica]

Já teda nevím ale mi to přijde jako naprosto nepodstatná informace, která může dávat smysl jedině když hnije nějaká služba. Celková hodnota u všech strojů na kterých jsem to spouštěl je totiž plus mínus stejná ~ 20–22 sekund.

[Heron]

Je celkem zajímavé, jak se liší časy v kernelu. Jako tohle poměřování velikosti péra nedává žádný smysl bez znalosti konkrétní distribuce, verze kernelu, HW a nastavení biosu. A nedává vlastně ani žádný smysl sám o sobě. Důležitější je blame a critical-chain.

systemd-analyze time
Startup finished in 4.748s (kernel) + 8.722s (userspace) = 13.470s 
graphical.target reached after 8.710s in userspace

systemd-analyze blame | head -n 10
7.144s systemd-networkd-wait-online.service
 668ms dev-sdb1.device                     
 645ms lightdm.service                     
 634ms systemd-logind.service              
 369ms systemd-networkd.service            
 365ms systemd-modules-load.service        
 346ms systemd-resolved.service            
 321ms systemd-journald.service            
 294ms systemd-timesyncd.service           
 276ms mnt-backup.mount

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 @8.710s
└─multi-user.target @8.710s
  └─hddtemp.service @8.693s +16ms
    └─network-online.target @8.690s
      └─systemd-networkd-wait-online.service @1.545s +7.144s
        └─systemd-networkd.service @1.163s +369ms
          └─systemd-udevd.service @1.121s +34ms
            └─systemd-tmpfiles-setup-dev.service @1.062s +22ms
              └─systemd-sysusers.service @966ms +41ms
                └─systemd-remount-fs.service @754ms +168ms
                  └─systemd-journald.socket @460ms
                    └─system.slice @168ms
                      └─-.slice @168ms

Z nějakého prapodivného důvodu se čeká 7s na dostupnost sítě. Statická konfigurace. Ze 13s celkově je to docela zajímavý čas. Ale nemá to smysl řešit. Bootoje se jednou denně a třeba čas v POST (5s) a následně GRUBu (10s) je delší, než celý boot linuxu.

[Peter Golis]

Niektoré distribúcie zvykli overovať či nakonfigurovaná IPka už náhodou nie je na sieti, a na tom to čakalo odhadom nejakých 5 sekúnd.

Ale inak súhlas. Tie časy závisia hlavne od typu pevného disku (NVMe, SSD alebo HDD), potom náväzností služieb a ich objemu. A že počítač štartuje raz za čas? Ja NB zvyknem štartovať tak raz za týždeň, zvyšok je zaklapnutý (s2ram alebo hibernácia).

Takže výsledkom budú akurát cca tri peaky pre spomenuté typy bežných pevných diskov. Ak sem ovšem niekto nedá štart nejakej krabičky z pomalého USB lízatka.

PS: Pamätám si ako mi zdržoval boot zázznam v /etc/fstab ktorý bol pre NFS exportovaný z na tom NB hosťovanej virtuálky. Hypervízor KVM mi čakal na sieť ktorá bola cez WiFi. To som mal hneď predĺžený boot o cca minútu, lebo rotačný disk.

[Heron]

Niektoré distribúcie zvykli overovať či nakonfigurovaná IPka už náhodou nie je na sieti, a na tom to čakalo odhadom nejakých 5 sekúnd.

Tohle řeší ARP / ICMPv6, na tom nemá co trvat 5s.

Jinak celé tohle cvičení mě přivedlo k myšlence, zda lze jakýkoliv NM (interfaces, network-manager, systemd-network) prostě nahradit jednou oneshot unitou, ve které se prostě natvrdo síť nastaví sérií ip příkazů (tj minimálně ip link dev set up; ip address add; ip route add default). Tj pro staticky nastavované sítě (tj všechny moje) by to mohlo být takto jednoduché.

[Peter Golis]

Tohle řeší ARP / ICMPv6, na tom nemá co trvat 5s.

On je tam timeout na odpoveď, a tých 5s bolo u mňa reálne zdržanie v takom kroku. Ale človek si to všimol akurát tak na minimálnej inštalácii, bez GUI a s vypnutým bootsplash. Inak to mal perkryté.

[Heron]

Vypadá to, že se na desktopu dá systemd-networkd-wait-online.service bezpečně vypnout. (Na serveru nikoliv, na online.targetu závisejí služby.) Takže bez zbytečných zdržovaček:

Startup finished in 4.729s (kernel) + 3.049s (userspace) = 7.778s 
graphical.target reached after 3.026s in userspace

Což celkem jde.

[Aleš Kapica]

No to už je mnohem lepší! A ještě jeden zajímavý příkaz jsem dnes "objevil" – loginctl

[Dušan]

Tak mne vyšlo

Startup finished in 13.121s (firmware) + 5.375s (loader) + 3.761s (kernel) + 10.158s (userspace) = 32.418s graphical.target reached after 10.150s in userspace

Hm, mám tam navyše firmware a loader....

Lenovo Thinkpad L15 ryzen + M2 SSD

[mirec]

3.943845s kernel + x.org

Thinkpad T420, SSD, openrc, gentoo.

[pavele]

systemd-analyze Startup finished in 2.446s (kernel) + 7.725s (userspace) = 10.172s

Thinkpad T420 s externím diskem do USB3 portu, Debian.

[mirec]

T420 nemá USB 3. USB3 expresscard?

[mirec]

Ešte prihadzujem video ako tá moja stará rachotina bootuje. Ako som spomínal je tam SSD (samsung evo 850), CPU i5-2520M, 16GB RAM, 1600MHz, integrovaná intel GPU a ešte výpis lspci:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Mobile SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
03:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
0d:00.0 SD Host controller: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 05)

[Peter Golis]

Nie je to CPU z časov, keď sa montovalo ECC do CPU CACHE L1, L2 a aj L3?

[mirec]

Fuu netuším ;)

[Peter Golis]

Na takéto drobné detaily je vo svete osobných počítačov príkaz dmidecode ale ten vyžaduje UEFI. To je už štandard posledných vyše 10 rokov.

[mirec]

L1, L2, L3 majú u mňa Error Correction Type: Single-bit ECC. Akurát neviem, či je to dobré, alebo nie ;)

[Peter Golis]

Je to dobré, ale nemoderné. Už sa od toho upúšťa.

[kulich]

kulich-LIFEBOOK-S751:~$ systemd-analyze Startup finished in 3.293s (kernel) + 43.785s (userspace) = 47.079s graphical.target reached after 9.512s in userspace

[VoDo]

Startup finished in 4.832s (kernel) + 10.691s (userspace) = 15.524s graphical.target reached after 10.689s in userspace raspberry 4

[Tilly Racker]

Bold byl servírka v naší tříletou cestu guitar lessons near me