Sinds ik met mijn Tumbleweed ben overgestapt op BTRFS merk ik dat het opstarten een stuk langzamer is,
jsteen@linux-lkq1:~> systemd-analyze
Startup finished in 6.156s (kernel) + 4.511s (initrd) + 1min 28.043s (userspace) = 1min 38.711s
jsteen@linux-lkq1:~>
De grootste boosdoener blijkt het volgende te zijn:
jsteen@linux-lkq1:~> systemd-analyze blame
1min 716ms systemd-journal-flush.service
10.877s apparmor.service
Is dit “normaal” of kan ik ergens iets instellen?
Normaal is 't niet, maar of 't te maken heeft met btrfs …
@knurpht:~> systemd-analyze blame | grep flush
656ms systemd-journal-flush.service
, maar da’s op XFS.
Ik zal 's even zoeken of ik hier wat over kan vinden. Heb op dit moment geen TW+btrfs machine ter hand.
Kun je 's output posten van
journalctl --disk-usage
en van
cat /etc/fstab
Ik heb 's even wat dingen gelezen bij andere distros mbt traag zijn, en daar beginnen mensen al te klagen als 't een paar seconden duurt, dus er zit ergens iets niet goed.
jsteen@linux-lkq1:~> journalctl --disk-usage
Hint: You are currently not seeing messages from other users and the system.
Users in the 'systemd-journal' group can see all messages. Pass -q to
turn off this notice.
Archived and active journals take up 16.0M on disk.
en deze:
jsteen@linux-lkq1:~> cat /etc/fstab
UUID=69649df9-a7eb-4faa-b399-35b2f4e0ca19 swap swap defaults 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 / btrfs defaults 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /opt btrfs subvol=@/opt 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /srv btrfs subvol=@/srv 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /tmp btrfs subvol=@/tmp 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /usr/local btrfs subvol=@/usr/local 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/cache btrfs subvol=@/var/cache 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/crash btrfs subvol=@/var/crash 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/lib/named btrfs subvol=@/var/lib/named 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/log btrfs subvol=@/var/log 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/opt btrfs subvol=@/var/opt 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/spool btrfs subvol=@/var/spool 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /var/tmp btrfs subvol=@/var/tmp 0 0
UUID=f1b7ef6e-cf49-4b05-91eb-953d710acc01 /.snapshots btrfs subvol=@/.snapshots 0 0
UUID=331207a3-19d0-4e0f-89c0-adb8020191d8 /home xfs defaults 1 2
jsteen@linux-lkq1:~>
fstab ziet er goed uit
Voor 't journalctl commando heb je root-rechten nodig
sudo journalctl --diskusage
Nog even verder lezend, kan 't ook te maken hebben met gecorrumpeerde journals, dit kun je checken met
sudo journalctl --verify
jsteen@linux-lkq1:~> sudo journalctl --disk-usage
[sudo] wachtwoord voor root:
Archived and active journals take up 97.8M on disk.
jsteen@linux-lkq1:~>
jsteen@linux-lkq1:~> sudo journalctl --verify
[sudo] wachtwoord voor root:
PASS: /var/log/journal/1acb2c39f355871584eee507577cd8ab/system.journal
PASS: /var/log/journal/1acb2c39f355871584eee507577cd8ab/user-1000.journal
jsteen@linux-lkq1:~>
Als ik het systeem herstart, en op “ESC” druk tijdens het opstarten dan zie ik dat systemd-journal-flush.service er lang duurt…
Op het Arch-forum vond ik dit:
https://bbs.archlinux.org/viewtopic.php?id=189775
En dit lijkt te werken.
Na het aanpassen van journald.conf start de boel inderdaad (een stuk) sneller op.
Nu:
jsteen@linux-lkq1:~> systemd-analyze
Startup finished in 6.148s (kernel) + 3.711s (initrd) + 20.036s (userspace) = 29.896s
jsteen@linux-lkq1:~>
jsteen@linux-lkq1:~> sudo journalctl --disk-usage
[sudo] wachtwoord voor root:
Archived and active journals take up 22.2M on disk.
jsteen@linux-lkq1:~>
:). Ik had 'm gezien, maar durfde 't niet aan om 't je zomaar uit te laten voeren:
Bij mij scheelt 't helemaal niks qua boot tijd. Wel zijn de journals gekrompen van 2.7GB naar ~80MB … En, dat moet toch ergens implicaties hebben, bedacht ik toen. En jawel, kon ik voorheen maanden terugkijken in de logs, weg, helemaal weg…
Wat ik bij het lezen steeds weer tegenkwam was corruptie van de journals. Op mijn server ( Leap ) ook maar 's even gekeken, en jawel die doet ruim 7 seconden over het flushen van de journals én meldt na verify van de logs dat er in /var/log/journal twee corrupte logs staan. Die weggesmeten, reboot en opnieuw kijken leidt tot 468ms …
ben niet zo bang 
Tumbleweed staat op mijn laptop, en wordt alleen door mij gebruikt.
Als ik iets nieuws wil proberen, dan doe ik dat op die laptop.
Mocht dat systeem crashen, is dat geen groot probleem. (liever niet natuurlijk)
Mijn “main” systeem wordt door de hele familie gebruikt, en moet dus stabiel zijn.
Daarop staat Leap, en ga ik echt niet in het wilde weg commando’s uitvoeren…
maar goed,
Blijft dan toch een beetje vreemd verhaal.
De kans bestaat dat het opstarten in de toekomst weer langzamer wordt.
Is het dan verstandig dat ik de restrictie in journald.conf weer verwijder?
Op dit moment zit je met dezelfde vragen als ik :D. Overigens ziet 't er bij mij zo’n beetje 't zelfde uit. Servert en de laptops van vrouw en kinderen draaien allemaal Leap. Ze updaten zelf, heb er weinig werk van. Mijn laptop heeft TW en (momenteel) Leap 42.2 Alpha