• Café

  • Bootzeiten und -Tuning Thread

brikler schrieb im übrigen kostet mich der getty@service kaum zeit, ich hab die NAutoVTs=2 .... aber mal sehen, vielleicht findet sich noch was 😃
Wie oben schon angesprochen - in meinem Fall wird über tty1 (autologin) die grafische Oberfläche direkt gestartet. Da bringt die Änderung in 'getty@.service' von 'idle' in 'simple' sehr viel: ich kann bereits die Arbeitsfläche verwenden, wenn der startup noch gar nicht abgeschlossen ist und spare bei Rechnern insbesondere mit WLAN etliche Sekunden - das bringt also richtig viel (deswegen auch der Tipp).

Zwei AutoVTs statt sechs - das bringt für mich keinen nennenswerten Vorteil - auf ein paar msecs hin oder her kommts mir da nicht an - so eine Anpassung muss schon Einsparungen im Sek.-Bereich bringen. Aber wenn's Spass macht - warum nicht. 😉
LessWire schrieb auf ein paar msecs hin oder her kommts mir da nicht an - so eine Anpassung muss schon Einsparungen im Sek.-Bereich bringen. Aber wenn's Spass macht - warum nicht. 😉
zum glück brauch ich mich beim userspace nicht mit sekunden abgeben sondern kann mich mit msec begnügen 😃 
Startup finished in 4.399s (firmware) + 1.231s (loader) + 916ms (kernel) + 552ms (userspace) = 6.099s
der wpa_supplicant.service hat mir doch glatt ~600ms gespart 🙂
21 Tage später
Bei mir liest sich die Zeile leider etwas anders:
Startup finished in 3.007s (firmware) + 3.897s (loader) + 8.957s (kernel) + 39.012s (userspace) = 54.874s
23 Sekunden verfallen davon auf mariadb:
graphical.target @39.000s
└─multi-user.target @39.000s
  └─mariadb.service @15.096s +23.903s
[…]

-- Reboot --
Aug 21 14:09:38 tesla systemd[1]: Starting MariaDB database server...
Aug 21 14:09:44 tesla mysqld[549]: 2016-08-21 14:09:44 140063025462464 [Note] /usr/sbin/mysqld (mysqld 10.1.16-MariaDB) starting as process 549 ...
Aug 21 14:09:45 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Using mutexes to ref count buffer pool pages
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: The InnoDB memory heap is disabled
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Memory barrier is not used
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Compressed tables use zlib 1.2.8
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Using Linux native AIO
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Using SSE crc32 instructions
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Initializing buffer pool, size = 128.0M
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:45 140063025462464 [Note] InnoDB: Completed initialization of buffer pool
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:09:46 140063025462464 [Note] InnoDB: Highest supported file format is Barracuda.
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:10:00 140063025462464 [Note] InnoDB: 128 rollback segment(s) are active.
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:10:00 140063025462464 [Note] InnoDB: Waiting for purge to start
Aug 21 14:10:00 tesla mysqld[549]: 2016-08-21 14:10:00 140063025462464 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.30-76.3 started; log sequence number 501548824
Aug 21 14:10:01 tesla mysqld[549]: 2016-08-21 14:10:01 140062587090688 [Note] InnoDB: Dumping buffer pool(s) not yet started
Aug 21 14:10:01 tesla mysqld[549]: 2016-08-21 14:10:01 140063025462464 [Note] Plugin 'FEEDBACK' is disabled.
Aug 21 14:10:02 tesla mysqld[549]: 2016-08-21 14:10:02 140063025462464 [Note] /usr/sbin/mysqld: ready for connections.
Aug 21 14:10:02 tesla mysqld[549]: Version: '10.1.16-MariaDB'  socket: '/run/mysqld/mysqld.sock'  port: 0  MariaDB Server
Aug 21 14:10:02 tesla systemd[1]: Started MariaDB database server.
6 Monate später
Startup finished in 2.895s (firmware) + 17ms (loader) + 1.154s (kernel) + 378ms (userspace) = 4.446s
unter 5 sekunden 😃
9 Tage später
brikler schrieb
Startup finished in 2.895s (firmware) + 17ms (loader) + 1.154s (kernel) + 378ms (userspace) = 4.446s
unter 5 sekunden 😃
Startup finished in 2.460s (firmware) + 27ms (loader) + 1.120s (kernel) + 315ms (userspace) = 3.923s
langsam bin ich zufrieden 😃

  • [gelöscht]

  • Beitrag Nr. 86
Pah. Da bin ich mit meiner Workstation im Büro weit von entfernt... 🙁 
Startup finished in 9.784s (firmware) + 477ms (loader) + 8.381s (kernel) + 24.049s (userspace) = 42.693s
13 Tage später
Schard-nologin schriebPah. Da bin ich mit meiner Workstation im Büro weit von entfernt... 🙁
es ist immer das selbe programm (ohne "schmutzige" hände): der schnellste code ist jener, den man nicht ausführen muß 😃
abschalten was man nicht unbedingt braucht oder wenns ned anders geht, mit einem timer nachträglich starten.

wenn die hände ruhig bissl dreckig werden dürfen, dann widmet man sich seiner modul blacklist und schaut auf was man verzichten kann.
als nächstes lädt man die module asynchron., zumindest mit dem 4.10er kernel geht das. 
module.async_probe [KNL]
			Enable asynchronous probe on this module.
https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
das "<modul>.async_probe" macht man nicht in der kernel command line sondern in /etc/modprobe.d… das ""<modul>.async_probe"" funktioniert leider nicht bei allen module, wenns blöd geht, geht gar nichts mehr.
und last, not least: die module konfiguriert man nicht beim laden, sondern wenns geht mit systemd tmpfiles
Startup finished in 10.136s (firmware) + 85ms (loader) + 25.964s (kernel) + 1.231s (userspace) = 37.417s
Tja da häng ich ziemlich hinterher. Liegt jedoch an der Festplatten-Verschlüsselung. Glaub die Zeit in der ich das Passwort eintippe geht da mit rein.
Ich kann nicht klagen. Ohne irgendwelche speziellen Optimierungen unter 4s ist nicht schlecht für die relativ lahme Kiste (Athlon 5150). 🙂 
Startup finished in 2.816s (kernel) + 1.022s (userspace) = 3.839s
@mis
da fehlen die loader und firmware phase, die sind nicht mit gemessen 😉
brikler schrieb@mis
da fehlen die loader und firmware phase, die sind nicht mit gemessen 😉
Das hat mich auch schon gewundert. 😉
Wie ist denn der Befehl dafür? Ich habe systemd-analyze benutzt..

Edit: Wird wohl nicht mit gemessen bei einem legacy-boot system.
mis schrieb Edit: Wird wohl nicht mit gemessen bei einem legacy-boot system.
da müsstest du "systemd" bei den hooks in der mkinitcpio.conf eintragen…aber wer tut das schon freiwillig?^^
Damit sieht es so aus 
Startup finished in 1.639s (kernel) + 1.372s (initrd) + 998ms (userspace) = 4.010s
Na egal, wird so irgendwas um die 10s sein insgesamt. 😉
7 Tage später
Startup finished in 9.586s (firmware) + 144ms (loader) + 1.354s (kernel) + 450ms (userspace) = 11.536s
Startup finished in 2.968s (firmware) + 19ms (loader) + 1.041s (kernel) + 291ms (userspace) = 4.320s
ein "kleiner" unterschied, mit ansonsten fast gleichen einstellungen.
"fast gleich", beim ersten hab ich die uuid benutzt und nicht die alt ehrwürdige /dev/ schreibweise

als merke: wer ungeduldig ist, bleibt bei der /dev und vermeidet die uuid^^
ein Monat später
LessWire schriebso eine Anpassung muss schon Einsparungen im Sek.-Bereich bringen.
so etwas fand ich gestern durch zufall: den swap erst nachträglich starten.
systemd vertrödelt da eine unmenge zeit. bei meinem zweiten notebook, mit lahmer hdd, sparte das gut 5 sekunden

https://forum.archlinux.de/viewtopic.php?id=30463
9 Monate später
Startup finished in 2.898s (kernel) + 884ms (userspace) = 3.782s

mal wieder

Startup finished in 1.121s (kernel) + 448ms (userspace) = 1.570s

mit selbst gebautem systemd und ohne efi, sonst kämen noch mal zw1schen 2,5 und 3,5 sekunden dazu.

4 Jahre später

da hab ich mich zu früh gefreut
Startup finished in 1.404s (kernel) + 1.455s (userspace) = 2.859s
früher wahr alles besser, oder was macht systemd jetzt anders als früher?

  • Dirk hat auf diesen Beitrag geantwortet.
  • brikler gefällt das.

    brikler Das klärst du aber bitte in einem neuen Thread und nicht in einem, in dem seit drei Jahren keine Aktivität mehr stattfand 🙂

      Dirk hat die Diskussion geschlossen ().