Re: [opensuse-project] Raspi3 boot imes (was: No info. re Leap 15.1 in Wikipedia)

25 Jan 2019


      On jeudi, 24 janvier 2019 11.53:34 h CET Axel Braun wrote:
...
...
Gesendet: Donnerstag, 24. Januar 2019 um 08:53 Uhr
Von: "Matthias Brugger" 
An: "Basil Chupin" , opensuse-project
 Cc: "nicolas saenz julienne"

Betreff: Re: [opensuse-project] No info. re Leap 15.1 in Wikipedia
I think we read about people complaining on the performance of openSUSE
this week already. I haven't done any measurements but heard that on
Raspberry Pi 3, Debian is significantly faster in booting then openSUSE.
Raspi are heavily depending on the kind of 'hard disk' you are using,
whether it is a SD card (connected via USB2) or an internal SSD Here is the
result of a Raspi using a Leap 15 LXQT image:
/home/test # systemd-analyze blame
    1min 30.071s display-manager.service
    1min 18.481s backup-rpmdb.service
         14.815s ca-certificates.service
         13.788s postfix.service
         12.885s btrfsmaintenance-refresh.service
         11.001s apparmor.service
         10.121s logrotate.service
          9.277s backup-sysconfig.service
          7.925s ModemManager.service
          7.755s lvm2-monitor.service
          5.889s NetworkManager.service
          5.086s postgresql.service
          4.790s initrd-switch-root.service
          3.074s systemd-journal-flush.service
          2.868s nscd.service
          2.721s kbdsettings.service
          2.672s sshd.service
          2.316s ntpd.service
          2.191s avahi-daemon.service
          2.153s systemd-udevd.service
          1.967s polkit.service
          1.959s user@1000.service
          1.299s systemd-tmpfiles-setup-dev.service
          1.171s systemd-remount-fs.service
          1.095s sys-kernel-debug.mount
           943ms systemd-logind.service
           920ms upower.service
           803ms wpa_supplicant.service
           789ms dev-mqueue.mount
           736ms dev-hugepages.mount
           715ms boot-efi.mount
           598ms udisks2.service
           493ms systemd-journald.service
           482ms initrd-parse-etc.service
           440ms systemd-udev-trigger.service
           436ms systemd-modules-load.service
           435ms auditd.service
           403ms dracut-cmdline.service
           348ms systemd-random-seed.service
           251ms initrd-cleanup.service
           250ms systemd-tmpfiles-setup.service
           247ms systemd-sysctl.service
           210ms systemd-update-utmp-runlevel.service
           207ms
dev-disk-by\x2duuid-d90960ec\x2df373\x2d472d\x2d8b3f\x2d27a48d232d7a.swap
193ms systemd-fsck-root.service
           184ms plymouth-switch-root.service
           170ms sysroot.mount
           166ms sys-fs-fuse-connections.mount
           159ms systemd-user-sessions.service
           151ms kmod-static-nodes.service
           112ms systemd-rfkill.service
            98ms plymouth-quit.service
            97ms plymouth-read-write.service
            85ms systemd-vconsole-setup.service
            76ms rtkit-daemon.service
            60ms dracut-shutdown.service
            51ms check-battery.service
            51ms systemd-update-utmp.service
            21ms initrd-udevadm-cleanup-db.service
            18ms sys-kernel-config.mount
            16ms plymouth-quit-wait.service
Quite strange, btrfsmaintenance and lvm2-monitor enabled, although both are
not used. Clearly most time is burned on display-manager and backup of the
rpm-db (could this not be moved to a systemd-timer triggered event at a
later point in time?)
Cheers
Axel
Most of the service you see there aren't they systemd timers that run because 
it was not running during their normal schedule. 
Did you try to reboot half an hour after this boot how it behaves ?

Ahrrr tests :-)

-- 

Bruno Friedmann 
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe supporter
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot


-- 
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org
To contact the owner, email: opensuse-project+owner@opensuse.org