Forums Neueste Beiträge
 

systemd vs. sysvinit (initd)

17/05/2012 - 10:09 von Andreas Hartmann | Report spam
Hallo allerseits,

ich habe spaßeshalber mal ein systemvinit-System mit einem
systemd-System verglichen. Systemd soll ja _der_ Bootbeschleuniger sein
... .

Beide Testsysteme haben grundsàtzlich dieselbe Partitionierung.


System alt:
openSUSE 11.4, Intel Celeron M, single core

System neu:
openSUSE 12.1, Intel Core i5, quad core

alt neu
hdparm -t 36 80 MB/s
hdparm -T 480 2624 MB/s


Von der Hardware her ergibt sich eine klare Erwartungshaltung: das neue
System sollte deutlich schneller booten, als das alte. Die viel gelobte
Parallelisierung bei systemd sollte einen Boot in Rekordzeit erwarten
lassen auf dem neuen System Dank 4 Cores und einer mindestens doppelt so
schnellen Platte.

Die Startkonfiguration ist bei beiden Systemen auf das Nötigste
beschrànkt (also kein nscd oder ntp oder dhcp oder àhnliche
Netzwerkscherze).


Das ist die Praxis:


init 3 init 5 (bis kdm)
alt neu alt neu
-
ab Grub/Kernelstart 27s 59s 36s 29s


Auffàllig ist init 3 beim Neusystem. An dieser Stelle muß ein Defekt
vorliegen. Es sieht danach aus, als ob ein Timeout auftreten würde bis
die Login-ttys gestartet werden, da lange Zeit keine
Festplattenaktivitàt vorliegt und auch keine Prozessorlast. Allerdings
bringt selbst das Aktivieren des Debug-Outputs keine Klarheit.
Seltsamerweise tritt das Problem bei init 5 nicht auf (sobald kdm
verfügbar ist, sind in diesem Fall auch die Login-Sessions auf der
Konsole schon da).

init 5 beim Neusystem (hier sind keine timeouts erkennbar) ist
sagenhafte 7 s schneller als beim Altsystem. Das ist, bezogen auf die
Hardwareunterschiede zwischen den beiden Systemen und dem Anspruch von
systemd, làcherlich.


Zu beurteilen, in wie weit systemd nun die Bootzeit beschleunigt im
Vergleich zu sysvinit, überlasse ich nun dem Leser.


Einige weitere Feststellungen zum Handling, die aufgefallen sind:

"systemctl disable remote-fs.target" hat schlicht nicht funktioniert
(obwohl der Befehl das Gegenteil behauptet hat).
chkconfig -d network-remotefs hat dagegen funktioniert.

z.B. sshd durchstarten (sshd ist ein harmloses Beispiel):
systemd: systemctl restart sshd.service
sysvinit: /etc/init.d/sshd restart

-> bei systemd weit mehr Tipparbeit, da kein autocompletion vorhanden.


Wie soll das Starten eines dedizierten Netzwerkinterfaces funktionieren?
sysvinit: /etc/init.d/network start eth5 -o manual
systemd: ?


Es wird behauptet, daß keine Abhàngigkeiten mehr definiert werden müßten
für die einzelnen Schritte.
Am Beispiel /lib/systemd/system/systemd-modules-load.service:

After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target

oder:
/lib/systemd/system/console-kit-log-system-restart.service
After=sysinit.target console-kit-log-system-start.service
Before=shutdown.target


Aktivieren des Debugging (gemàß http://en.opensuse.org/SDB:Systemd):

Kernel command line: systemd.log_target=kmsg systemd.log_level=debug
systemd.sysv_console=1 (macht besonders viel Spaß mit englischem
Tastaturtreiber und deutscher Tastatur).

-> ich habe keine Verànderungen bemerkt.


Das waren einfach ein paar Feststellungen mit keinerlei Anspruch auf
Vollstàndigkeit.


Andreas
 

Lesen sie die antworten

#1 Ulf Volmer
17/05/2012 - 12:24 | Warnen spam
Andreas Hartmann schrieb:

[systemd/versus sysv]

init 3 init 5 (bis kdm)
alt neu alt neu
-
ab Grub/Kernelstart 27s 59s 36s 29s



Du kann bei systemd die Zeiten der Servicestarts sehr schön
visualisieren:

systemd-analyze plot > plot.svg

Vielleicht fàllt dabei ja der Überltàter auf.

Gruß,
Ulf.

Ähnliche fragen