[gelöst] sytemd und bootgeschwindigkeit

[mullers]

Ich habe jetzt hier schon öfter gelesen, dass mit systemd der Bootvorgang sehr viel schneller vonstatten gehen soll. Als Referenzgröße wird gerne `Schmidts Katze' genommen (`schnell wie Schmidts Katze').
Hier allerdings hat sich seit ich systemd habe, nichts spürbar geändert. Vielleicht weil ich `Schmidts Katze' nicht kenne, oder aber weil, wie es auch gerüchteweise hieß, dafür eine Neuinstallation nötig sei.

Ist es nun schneller, muss ich dafür neuinstallieren (dann werde ich auf den überwältigenden Performanceboost allerdings verzichten)?

Gruesse
henry

[owl102]

Was sagt

Code: Alles auswählen

systemd-analyze blame

?

[mullers]

Was sagt

Code: Alles auswählen

systemd-analyze blame

?

Code: Alles auswählen

25.036s preload.service
         17.148s systemd-udev-settle.service
         17.043s early-readahead.service
          5.599s systemd-fsck@dev-disk-by\x2duuid-fef558ab\x2d5
          5.207s systemd-fsck@dev-mapper-bye\x2dhome.service
          3.746s ModemManager.service
          3.115s systemd-fsck-root.service
          3.056s lvm2-activation-early.service
          1.297s lvm2-activation.service
          1.273s systemd-modules-load.service
          1.059s systemd-tmpfiles-clean.service
           986ms dev-mqueue.mount
           983ms systemd-udev-trigger.service
           979ms rc-local.service
           947ms dev-hugepages.mount
           931ms sys-kernel-debug.mount
           827ms lvm2-monitor.service
           615ms keyboard-setup.service
           594ms systemd-backlight@backlight:acpi_video0.servic
           512ms networking.service
           505ms console-kit-log-system-start.service
           504ms alsa-restore.service
           495ms pppd-dns.service
           466ms systemd-rfkill@rfkill0.service
           449ms user@1000.service
           391ms binfmt-support.service
           369ms systemd-logind.service
           328ms virtualbox.service
           327ms kexec.service
           285ms systemd-tmpfiles-setup-dev.service
           266ms kbd.service
           222ms udisks2.service
           208ms packagekit.service
           207ms wicd.service
           198ms polkitd.service
           194ms kmod-static-nodes.service
           192ms gpm.service
           175ms home.mount
           174ms systemd-udevd.service
           170ms hdparm.service
           168ms systemd-remount-fs.service
           163ms udev-finish.service
           131ms console-setup.service
           118ms systemd-cryptsetup@sda2_crypt.service
           115ms systemd-sysctl.service
           104ms systemd-random-seed.service
            99ms systemd-user-sessions.service
            95ms loadcpufreq.service
            85ms acpi-support.service
            65ms console-kit-daemon.service
            62ms dev-mapper-bye\x2dswap_1.swap
            44ms systemd-update-utmp.service
            38ms systemd-tmpfiles-setup.service
            31ms apmd.service
            26ms rsyslog.service
            26ms boot.mount
            24ms kexec-load.service
            23ms cpufrequtils.service
            16ms lpd.service
            16ms later-readahead.service
             8ms proc-sys-fs-binfmt_misc.mount
             8ms keymap.service
             6ms systemd-update-utmp-runlevel.service
             6ms systemd-journal-flush.service
             6ms sys-fs-fuse-connections.mount
             5ms lvm2-pvscan@254:0.service
             4ms stop-readahead-fedora.service

[Lord_Carlos]

Mhh, hast du mal so ein readahead ding selber installiert?
Bei mir wird das nicht gestartet.

[JuergenPB]

Was sagt

Code: Alles auswählen

systemd-analyze blame

?

Code: Alles auswählen

25.036s preload.service
         17.148s systemd-udev-settle.service
…

Schau mal da:

http://freedesktop.org/wiki/Software/sy ... mizations/

What you can optimize (locally) without writing any code:

1. Make sure not to use any fake block device storage technology such as LVM (as installed by default by various distributions, including Fedora) they result in the systemd-udev-settle.service unit to be pulled in. Settling device enumeration is slow, racy and mostly obsolete. Since LVM (still) hasn't been updated to handle Linux' event based design properly, settling device enumeration is still required for it, but it will slow down boot substantially. On Fedora, use "systemctl mask fedora-wait-storage.service fedora-storage-init-late.service fedora-storage-init.service" to get rid of all those storage technologies. Of course, don't try this if you actually installed your system with LVM. (The only fake block device storage technology that currently handles this all properly and doesn't require settling device enumerations is LUKS disk encryption.)

[mullers]

Als ich den output von 'systemd-analyze blame' gepostet hatte, sind mir auch die beiden Bremsen aufgefallen (preload, readahead). Ich habe sie daraufhin gleich mal deinstalliert. Hatte ich mal vor Jahren installiert && vergessen. Das erhöht die Bootgeschwindigkeit, bzw. das Fehlen der beiden Progrämmchen stutzt sie jetzt wieder auf Normalmaß zurück.
Okay, bootet jetzt natürlich besser, aber so eine gute Minute ist jetzt auch nichts, womit man beeindrucken kann.

[mindX]

Code: Alles auswählen

17.043s early-readahead.service
5.599s systemd-fsck@dev-disk-by\x2duuid-fef558ab\x2d5

Vorausgesetzt, ich lese das richtig, dann würde ich da ne ziemliche Lücke sehen. Auf Verdacht: Kann es sein, dass jedes Mal ein fsck läuft?

Als root oder du fügst deinen user zur Gruppe systemd-journal hinzu:

Code: Alles auswählen

journalctl | grep fsck

[Lord_Carlos]

Das erhöht die Bootgeschwindigkeit, bzw. das Fehlen der beiden Progrämmchen stutzt sie jetzt wieder auf Normalmaß zurück.
Okay, bootet jetzt natürlich besser, aber so eine gute Minute ist jetzt auch nichts, womit man beeindrucken kann.

Ist es jetzt schneller als noch mit dem alten system?
Ja, ne Minute ist relativ lang, aber ich nehme an du hat eine HDD verbaut?

[mullers]

Ja, es ist mit HDD.
So, ich habe noch mal gemessen. Bis zum Anmeldebildschirm komme ich auf etwa 45 sek. plus minus. Das ist, denke ich, gar nicht mal so schlecht. Der Bootvorgang sollte sich nach den Veränderungen signifikant über 30 sek. verbessert haben, das ist ja schon mal sehr viel.
Bezüglich fsck. Ja, das ist mir dann auch aufgefallen, dass das immer lief. Und ich weiss jetzt auch warum. Bevor ich preload/readahead desinstalliert habe, fuhr der Rechner nie ordentlich runter, musste immer den Stecker ziehen im Laufe des, angehaltenen, shutdown. Jetzt fährt er vollständig herunter, und fsck läuft natürlich dann nicht mehr, weil nicht mehr nötig.

Alles in Allem ist das was man wohl rausholen konnte, jedenfalls bin ich zufrieden, und markiere den Thread deshalb mit einem gelöst.

Dank an Alle!

[JTH]

Vorausgesetzt, ich lese das richtig, dann würde ich da ne ziemliche Lücke sehen.

Das hast du tatsächlich nicht ganz richtig gelesen. systemd-analyze blame zeigt die Zeit, die einzelne Dienste zum Starten gebraucht haben, und nicht die Zeitpunkte, zu denen sie gestartet wurden.

[mindX]

Vorausgesetzt, ich lese das richtig, dann würde ich da ne ziemliche Lücke sehen.

Das hast du tatsächlich nicht ganz richtig gelesen. systemd-analyze blame zeigt die Zeit, die einzelne Dienste zum Starten gebraucht haben, und nicht die Zeitpunkte, zu denen sie gestartet wurden.

Danke, wieder was gelernt!

[smutbert]

Auf einige der Dienste/Startskripte/systemd-units könntest du vielleicht noch verzichten, etwa consolekit, apmd, gpm, acpi-support/acpi-support-base, hdparm, modemmanager,… (natürlich nur wenn die Abhängigkeiten und deine Anforderungen es erlauben)

Dann wäre vielleicht noch die eine andere Sekunde drin, aber den größten Brocken (lvm2 und das was es hinter sich herzieht) wirst du wohl nicht so einfach los.

[mullers]

Dann wäre vielleicht noch die eine andere Sekunde drin, aber den größten Brocken (lvm2 und das was es hinter sich herzieht) wirst du wohl nicht so einfach los.

Oh ja, wem sagst du das....
Dabei brauche ich es eigentlich gar nicht wirklich (wobei einmal hatte ich wirklich die root Partition vergrößert). Allein schon anfangs immer diese dämliche Fehlermeldung... Na, ja, demnächst ist ein neues Notebook fällig, dann wird auf diesem hier neuinstalliert.

[JuergenPB]

So, ich habe noch mal gemessen. Bis zum Anmeldebildschirm komme ich auf etwa 45 sek. plus minus…

Gibt doch mal ein:

Code: Alles auswählen

systemd-analyze plot > zeitdiagramm.svg

Das erzeugt eine Grafik aus der Du sehen kannst, was parallel gestartet wird und was nacheinander und wie lange alles zusammen so dauert. – Dann brauchst Du auch keine Stoppuhr zum Messen.

[joahlen]

Gibt doch mal ein:

Code: Alles auswählen

systemd-analyze plot > zeitdiagramm.svg

Das erzeugt eine Grafik aus der Du sehen kannst, was parallel gestartet wird und was nacheinander und wie lange alles zusammen so dauert. – Dann brauchst Du auch keine Stoppuhr zum Messen.

Genial. Danke für den Tipp. Übrigens kommt meine Kiste (M55, siehe Signatur) auf 6 sek. mit uralt SSD.

JO

[scientific]

Möchte mich auch kurz anhängen.
Bei mir sieht die critical-chain so aus

Code: Alles auswählen

# systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @50.855s
└─multi-user.target @50.855s
  └─mailserver.target @50.855s
    └─fetchmail@jakob.service @50.854s
      └─exim4.service @26.192s +24.603s
        └─cyrus-imapd.service @25.336s +854ms
          └─amavis.service @9.930s +15.404s
            └─basic.target @9.839s
              └─paths.target @9.838s
                └─acpid.path @9.838s
                  └─sysinit.target @9.838s
                    └─plymouth-log.service @9.836s +1ms
                      └─console-setup.service @9.712s +122ms
                        └─kbd.service @9.635s +76ms
                          └─nfs-common.service @9.054s +579ms
                            └─rpcbind.target @9.054s
                              └─rpcbind.service @8.839s +214ms
                                └─network-online.target @8.839s
                                  └─network.target @8.839s
                                    └─networking.service @6.331s +2.507s
                                      └─pppd-dns.service @6.052s +279ms
                                        └─hdparm.service @5.824s +226ms
                                          └─keyboard-setup.service @4.157s +1.666s
                                            └─keymap.service @4.137s +18ms
                                              └─qemu-system-x86.service @3.777s +359ms
                                                └─systemd-udevd.service @3.673s +103ms
                                                  └─systemd-tmpfiles-setup-dev.service @3.016s +656ms
                                                    └─kmod-static-nodes.service @2.702s +305ms
                                                      └─system.slice @2.524s
                                                        └─-.slice @2.523s

Ich hatte leider noch nicht die Muse, mich mit der Socket-Aktivierung genauer auseinander zu setzen. Denn genau das bräuchte ich aktiv für mein "Mailserver.target". Der Mailserver verzögert nämlich das graphische Login erheblich...

Code: Alles auswählen

         25.409s spamassassin.service
         24.603s exim4.service
         15.404s amavis.service
         12.262s uml-utilities.service
         11.946s ModemManager.service
         10.349s NetworkManager.service
          9.517s dnsmasq.service
          9.123s accounts-daemon.service
          8.432s systemd-logind.service
          8.392s alsa-restore.service
          8.316s clamav-daemon.service
          8.301s saslauthd.service
          8.300s rc-local.service
          8.299s minissdpd.service
          8.299s binfmt-support.service
          8.295s bluetooth.service
          8.291s avahi-daemon.service
          6.023s systemd-cryptsetup@mars.service
          3.528s fail2ban.service
          3.350s btkbd.service
          2.780s apache2.service
          2.507s networking.service
          2.267s var-cache-backup.mount
          1.666s keyboard-setup.service
          1.428s wpa_supplicant.service
          1.150s gdm.service
           950ms rsyslog.service
           935ms loadcpufreq.service
           854ms cyrus-imapd.service
           709ms amavisd-snmp-subagent.service
           656ms systemd-tmpfiles-setup-dev.service
           613ms systemd-modules-load.service
           611ms gpm.service
           610ms polkitd.service
           579ms nfs-common.service
           578ms cpufrequtils.service
           495ms systemd-udev-trigger.service
           480ms dev-mqueue.mount
           423ms amavis-mc.service

Und auch hier erkennt man die Verzögerung gut. Eigentlich würde es nämlich bei mir reichen, den Mailserver beim ersten Abruf von Mails, oder eine bestimmte Zeit nach dem Booten zu starten. Ich kann nur momentan grad nicht testen, weil ich ein initiales Backup von einigen GB laufen habe... und da kommt ein Reboot nicht gaaaanz so gut