[yaVDR-Ansible] "Umfrage" Bootzeiten ...

davie2000 · September 5, 2019 at 12:11 AM

Hallo!

Mich würde interessieren, wie lange ihr mit yaVDR-Ansible zum Booten braucht, damit ich meine Zeiten besser einordnen kann.

Im Schnitt sinds 13 Sekunden lt. systemd-analyze mit denen wir ziemlich zufrieden sind:

Code

Startup finished in 3.764s (kernel) + 8.795s (userspace) = 12.560s
graphical.target reached after 8.766s in userspace

Von SSD mit Skindesigner, EPGD & Co und Softhddevice (Openglosd FFMpeg 2.8) und noch anderen Plugins (wie zB Live) - und nach der Installation von Preload.

Dieter · September 5, 2019 at 1:43 PM

Hi,

13 sec wären klasse. Hier ist es mehr um die 60 (von SSD) bis Bild kommt. systemd-analyze sagt auch was von ~13 sec.

Code

Startup finished in 3.456s (kernel) + 9.828s (userspace) = 13.284s
graphical.target reached after 9.811s in userspace

seahawk1986 · September 5, 2019 at 2:21 PM

Die Zeit, die der Rechner im BIOS/UEFI verbringt und eine eventuelle Verzögerung durch einen eventuell eingestellten Grub-Timeout können von systemd-analyze naturgemäß nicht erfasst werden.

Der UEFI Fastboot und das Abschalten von nicht benötigter Hardware bzw. der automatischen Erkennung von Geräten an IDE- und SATA-Anschlüssen kann da je nach Systemkonfiguration einiges bringen.

Wenn das Netzwerk früh da ist, aber satip länger braucht, könnte ggf. eine statische Konfiguration des SAT>IP Servers helfen, dann spart man sich die Phase mit der Erkennung der Geräte im Netzwerk.

davie2000 · September 5, 2019 at 9:46 PM

Quote from Dieter

13 sec wären klasse. Hier ist es mehr um die 60 (von SSD) bis Bild kommt. systemd-analyze sagt auch was von ~13 sec.

Bei uns ist Bild u Ton nach ca. 20 Sekunden (gestoppt mit dem Handy) da.

In den ersten Sekunden danach reagiert der VDR noch etwas träge, aber das pendelt sich schnell ein.

Ich liste hier noch die "schuldigsten" Dienste auf - Ausgabe von systemd-analyze blame (absteigend bis ca. 400 ms):

Code

          3.199s dev-sdb1.device
          1.924s vdr.service
          1.762s systemd-networkd-wait-online.service
          1.514s postfix@-.service
          1.472s mariadb.service
          1.156s x@vt7.service
           924ms networkd-dispatcher.service
           831ms udisks2.service
           762ms systemd-journal-flush.service
           718ms lircd-setup.service
           622ms snapd.service
           572ms keyboard-setup.service
           520ms motd-news.service
           504ms lvm2-monitor.service
           409ms grub-common.service
           384ms smbd.service
           331ms nfs-server.service
           315ms systemd-resolved.service
           303ms nmbd.service
           295ms epghttpd.service
           288ms proc-fs-nfsd.mount

Display More

systemd-networkd-wait-online.service hat früher zB deutlich länger gebraucht und wurde durch die statische IP-Adresse deutlich schneller.

=> Kennt ihr noch andere Möglichkeiten, wie ich einige davon noch schneller bekomme (zB dev-sdb1.device)?

Außerdem würden mich noch Bootzeiten bzw. Zeiten bis Bild/Ton von anderen/mehreren yaVDR-Ansible-NutzerInnen interessieren ...

Negge · September 25, 2019 at 7:37 PM

Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 2TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless

Code

Startup finished in 3.274s (kernel) + 1min 33.453s (userspace) = 1min 36.727s
graphical.target reached after 1min 33.442s in userspace

Code

systemd-analyze blame
         19.768s apt-daily.service
          3.317s webmin.service
          2.694s vdr.service
          1.934s systemd-networkd-wait-online.service
          1.766s dev-sda1.device
          1.439s mariadb.service
          1.308s postfix@-.service
          1.018s networkd-dispatcher.service
          1.011s x@vt7.service
           817ms lircd-setup.service
           659ms motd-news.service
           585ms snapd.service
           566ms apparmor.service
           487ms lvm2-monitor.service
           421ms accounts-daemon.service
           404ms grub-common.service
           365ms nmbd.service
           348ms keyboard-setup.service
...

Display More

beinhart · September 25, 2019 at 9:54 PM

mit nem NUC8i3BEK sieht es hier so aus (bild und ton nach ca. 15 sec):

Code

systemd-analyze
Startup finished in 2.916s (kernel) + 6.522s (userspace) = 9.438s
graphical.target reached after 6.510s in userspace

Code

systemd-analyze blame
          4.234s systemd-networkd-wait-online.service
          1.278s vdr.service
           690ms systemd-journal-flush.service
           570ms apt-daily.service
           486ms x@vt7.service
           434ms dev-sda1.device
           186ms networkd-dispatcher.service
           133ms keyboard-setup.service
           133ms systemd-logind.service
           129ms apparmor.service
            96ms systemd-udev-trigger.service
            85ms accounts-daemon.service
            85ms plymouth-quit.service
            84ms plymouth-quit-wait.service
            80ms grub-common.service
            77ms swapfile.swap
            73ms nfs-server.service
            71ms thermald.service
            63ms proc-fs-nfsd.mount
            60ms srv-vdr-video.mount
            55ms nfs-mountd.service
            54ms rpcbind.service
            53ms systemd-resolved.service
            52ms systemd-journald.service
            47ms wpa_supplicant.service
            46ms user@666.service
            45ms avahi-daemon.service
            41ms ssh.service
            41ms media-nfk.mount
            38ms systemd-sysctl.service
            35ms systemd-networkd.service
            34ms apport.service
            30ms polkit.service
            30ms user@0.service
            28ms rsyslog.service
            27ms systemd-tmpfiles-setup-dev.service
            25ms plymouth-start.service
            24ms systemd-timesyncd.service
            24ms run-rpc_pipefs.mount
            22ms ureadahead-stop.service
            21ms plymouth-read-write.service
            19ms systemd-remount-fs.service
            19ms systemd-udevd.service
            18ms hddtemp.service
            17ms systemd-modules-load.service
            16ms kmod-static-nodes.service
            16ms dev-hugepages.mount
            16ms sys-kernel-debug.mount
            15ms autofs.service
            15ms lm-sensors.service
            11ms sys-kernel-config.mount
            11ms systemd-tmpfiles-setup.service
             9ms ufw.service
             8ms systemd-random-seed.service
             8ms nfs-idmapd.service
             7ms systemd-user-sessions.service
             7ms console-setup.service
             6ms sys-fs-fuse-connections.mount
             5ms dev-mqueue.mount
             5ms systemd-update-utmp.service
             5ms nfs-blkmap.service
             5ms systemd-update-utmp-runlevel.service
             4ms setvtrgb.service
             4ms rpc-statd.service
             2ms nfs-config.service
             2ms yavdr-xorg.service
             2ms rpc-statd-notify.service

Display More

davie2000 · September 25, 2019 at 10:14 PM

Das ist ja schnell!

Ich nehme an, deine sda1 ist eine SSD?

Ist das etwas besonders Schnelles, oder hast du die SSD irgendwie speziell angeschlossen?

Mein dev-sdb1.device braucht 5 mal so lange (> 2,5 Sekunden)???

Auch dein VDR-Service startet doppelt so schnell.

beinhart · September 25, 2019 at 10:21 PM

Quote from davie2000

Das ist ja schnell!

Ich nehme an, deine sda1 ist eine SSD?

Ist das etwas besonders Schnelles, oder hast du die SSD irgendwie speziell angeschlossen?

Mein dev-sdb1.device braucht 5 mal so lange (> 2,5 Sekunden)???

Auch dein VDR-Service startet doppelt so schnell.

die ssd ist absolut nichts besonderes, 08/15. im bios abgeschaltet, was nur abzuschalten ist. ansonsten ist nichts optimiert

hab da vier von am laufen, alle als client

folgende plugins sind aktiv:

Code

vdr (2.4.1/2.4.1) - The Video Disk Recorder
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
dbus2vdr (31) - control vdr via D-Bus
epg2vdr (1.1.98-GIT77af073) - epg2vdr plugin
epgsearch (2.4.0) - search the EPG for repeats and more
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
fritzbox (1.5.3) - Fritz Plugin for AVM Fritz!Box
menuorg (0.5.2) - Reorganizes the main menu
osdteletext (0.9.7) - Displays teletext on the OSD
pin (0.1.16) - Childlock plugin
pulsecontrol (0.2.1) - control settings of pulseaudio
quickepgsearch (0.0.1) - Quick search for broadcasts
restfulapi (0.2.6.5) - Offers a RESTful-API to retrieve data from VDR
scraper2vdr (1.0.11-GITd9f6cb4) - 'scraper2vdr' plugin
skindesigner (1.2.8) - Skin Designer
softhddevice (0.7.0-GIT3871118) - A software and GPU emulated HD device
streamdev-client (0.6.1-git) - VTP Streaming Client
systeminfo (0.1.5) - Display various system informations
tvguideng (0.3.1) - TV Guide for Skindesigner Skins
weatherforecast (0.2.0) - Weatherforecast based on forecast.io
zaphistory (0.9.6) - History of the last zapped channels

Display More

info zu ssd:

Code

=== START OF INFORMATION SECTION ===
Device Model:     CT250MX500SSD4
Serial Number:    1846E1D8218B
LU WWN Device Id: 5 00a075 1e1d8218b
Firmware Version: M3CR023
User Capacity:    250.059.350.016 bytes [250 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    Solid State Device
Form Factor:      M.2
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA >3.2 (0x1ff), 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Sep 25 22:25:43 2019 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enable

Display More

Uwe · September 26, 2019 at 9:10 AM

Hallo beinhart,

warum hast du conflictcheckonly, epgsearch, epgsearchonly und quickepgsearch zusammen am Start? Ich nutze nur epgsearch....

Gruß

Uwe

beinhart · September 26, 2019 at 9:20 AM

Quote from Uwe

Hallo beinhart,

warum hast du conflictcheckonly, epgsearch, epgsearchonly und quickepgsearch zusammen am Start? Ich nutze nur epgsearch....

Gruß

Uwe

gute frage - damit hab ich mich noch nie auseinandergesetzt. epgsearch hab ich einfach per paket installiert

Frodo · September 26, 2019 at 7:15 PM

Meine zwei YaVDR Ansible VDRs starten wie folgt:

1. VDR i5-2500T (4 DVB Tuner)

Code

Startup finished in 3.150s (kernel) + 19.596s (userspace) = 22.747s
graphical.target reached after 11.399s in userspace

Code

# systemd-analyze blame
         11.355s apt-daily.service
          6.771s systemd-networkd-wait-online.service
          2.292s vdr.service
          1.152s dev-mapper-vdr4\x2d\x2dvg\x2droot.device
          1.128s systemd-resolved.service
          1.005s x@vt7.service
          1.000s postfix@-.service
           880ms udisks2.service
           877ms lircd-setup.service
           787ms apparmor.service
           787ms networkd-dispatcher.service
           709ms lxd-containers.service
           653ms systemd-timesyncd.service
           638ms systemd-journal-flush.service
           616ms apt-daily-upgrade.service
           549ms accounts-daemon.service
           521ms motd-news.service
           487ms snapd.service
           456ms systemd-logind.service
           449ms rsyslog.service
           412ms grub-common.service
           367ms ebtables.service
           365ms wpa_supplicant.service
           335ms user@666.service
           311ms srv-ppa.mount
           279ms srv-vdr-video.mount
           275ms console-setup.service
           275ms srv-audio.mount
           233ms nfs-server.service
           204ms autofs.service
           195ms srv-video.mount
           184ms munin-node.service
           184ms srv-picture.mount
           184ms polkit.service
           178ms networking.service
           174ms nmbd.service
           168ms systemd-journald.service
           160ms nfs-idmapd.service
           146ms lvm2-monitor.service
           146ms proc-fs-nfsd.mount
           144ms keyboard-setup.service
           139ms smbd.service
           129ms alsa-restore.service
           127ms apport.service
           125ms lm-sensors.service
           114ms nfs-config.service
           110ms xymon-client.service
            90ms systemd-modules-load.service
            89ms systemd-sysctl.service
            84ms run-rpc_pipefs.mount
            81ms plymouth-quit-wait.service
            81ms plymouth-quit.service
            76ms systemd-tmpfiles-setup-dev.service
            75ms systemd-udev-trigger.service
            72ms dev-mqueue.mount
            71ms ssh.service
            71ms rpcbind.service
            68ms snapd.seeded.service
            68ms srv-video-Secure.mount
            66ms nfs-mountd.service
            65ms xinetd.service
            65ms nfs-blkmap.service
            60ms lvm2-pvscan@8:1.service
            60ms systemd-remount-fs.service
            60ms setvtrgb.service
            59ms systemd-update-utmp.service
            59ms dev-hugepages.mount
            59ms hddtemp.service
            58ms sys-kernel-debug.mount
            54ms systemd-random-seed.service
            51ms systemd-udevd.service
            48ms srv-vdr-video-Bea_und_Ingo.mount
            47ms user@0.service
            44ms srv-video-vsecure.mount
            42ms systemd-networkd.service
            40ms kmod-static-nodes.service
            39ms ufw.service
            27ms dev-mapper-vdr4\x2d\x2dvg\x2dswap_1.swap
            18ms systemd-tmpfiles-setup.service
            14ms plymouth-start.service
            13ms plymouth-read-write.service
            13ms blk-availability.service
            13ms systemd-tmpfiles-clean.service
            10ms ureadahead-stop.service
            10ms systemd-update-utmp-runlevel.service
             7ms systemd-user-sessions.service
             6ms nvidia-persistenced.service
             4ms sys-kernel-config.mount
             3ms sys-fs-fuse-connections.mount
             3ms yavdr-xorg.service
             2ms postfix.service
             2ms lxd.socket
             1ms snapd.socket

Display More

2. VDR i3-6100 (nur SAT-IP) UEFI

Code

Startup finished in 9.566s (firmware) + 1.888s (loader) + 2.829s (kernel) + 17.592s (userspace) = 31.876s
graphical.target reached after 11.135s in userspace

Code

# systemd-analyze blame
          9.602s apt-daily.service
          5.318s systemd-networkd-wait-online.service
          1.773s vdr.service
          1.418s keyboard-setup.service
          1.363s x@vt7.service
          1.211s postfix@-.service
          1.089s dev-mapper-vdr1\x2d\x2dvg\x2droot.device
          1.089s networkd-dispatcher.service
           958ms lircd-setup.service
           845ms snapd.service
           818ms systemd-journal-flush.service
           719ms motd-news.service
           578ms udisks2.service
           566ms grub-common.service
           564ms accounts-daemon.service
           557ms systemd-logind.service
           539ms lxd-containers.service
           534ms apt-daily-upgrade.service
           410ms systemd-resolved.service
           399ms networking.service
           375ms munin-node.service
           373ms srv-vdr-video.mount
           368ms srv-audio.mount
           347ms rsyslog.service
           346ms lm-sensors.service
           320ms smbd.service
           303ms srv-video.mount
           289ms srv-ppa.mount
           281ms apparmor.service
           278ms systemd-timesyncd.service
           273ms srv-picture.mount
           261ms systemd-rfkill.service
           244ms nfs-server.service
           244ms user@666.service
           238ms autofs.service
           214ms systemd-networkd.service
           209ms proc-fs-nfsd.mount
           204ms apport.service
           203ms nfs-mountd.service
           195ms wpa_supplicant.service
           193ms polkit.service
           189ms run-rpc_pipefs.mount
           182ms lvm2-monitor.service
           179ms systemd-modules-load.service
           179ms systemd-journald.service
           154ms systemd-tmpfiles-setup-dev.service
           141ms nmbd.service
           134ms alsa-restore.service
           108ms xinetd.service
           104ms systemd-random-seed.service
           103ms sys-kernel-debug.mount
           101ms dev-hugepages.mount
           100ms dev-mqueue.mount
            96ms systemd-remount-fs.service
            96ms snapd.seeded.service
            85ms xymon-client.service
            78ms systemd-sysctl.service
            75ms srv-vdr-video-Bea_und_Ingo.mount
            71ms srv-video-vsecure.mount
            69ms systemd-udevd.service

Display More

wojak_76 · September 26, 2019 at 8:01 PM

Hi,

I have SSD as well but my starting time is long. Where is the problem and how can I solve it.

systemd-analyze

Startup finished in 3.198s (firmware) + 38.891s (userspace) = 42.089s

graphical.target reached after 38.874s in userspace

systemd-analyze blame

26.063s data.mount

4.095s systemd-networkd-wait-online.service

3.552s vdr.service

2.514s dev-sdb2.device

Best regards.

seahawk1986 · September 26, 2019 at 8:13 PM

Quote from wojak_76

26.063s data.mount

What kind of filesystem is mounted by this unit?

wojak_76 · September 26, 2019 at 8:24 PM

Hi seahawk1986

There xfs file system. But even when I mark this disc in fstab not to mount the boot time is not improved.

seahawk1986 · September 26, 2019 at 8:38 PM

What is the output of systemd-analyze critical-chain if the disc is not mounted?

wojak_76 · September 26, 2019 at 8:59 PM

It is :

graphical.target @36.021s

└─multi-user.target @36.021s

└─vdr.service @32.494s +3.526s

└─x@vt7.service @31.372s +1.120s

└─basic.target @30.288s

└─sockets.target @30.288s

└─lxd.socket @30.281s +4ms

└─sysinit.target @30.268s

└─apparmor.service @4.148s +26.119s

└─local-fs.target @4.147s

└─run-user-666.mount @32.511s

└─local-fs-pre.target @1.783s

└─keyboard-setup.service @1.290s +492ms

└─systemd-journald.socket @1.279s

└─system.slice @1.277s

└─-.slice @1.274s

seahawk1986 · September 26, 2019 at 9:14 PM

You could try to disable apparmor: https://help.ubuntu.com/community/AppA…Armor_framework

pille2011 · September 27, 2019 at 6:02 PM

Bei mir 24s,ist ok!

Code

root@stube:/home/frank# systemd-analyze
Startup finished in 7.678s (kernel) + 16.386s (userspace) = 24.064s
graphical.target reached after 16.316s in userspace
root@stube:/home/frank#

presskopf · October 17, 2020 at 9:38 PM

Hallo zusammen,

ich buddel mal die Leiche aus, weil ein neuer Thread m.E. nicht zwingend lohnt.

Mein Produktivsystem (J4105M mit SSD und yavdr ansible unter Focal) ist, wenn ich mit Euren Zeiten deutlich langsamer. Warum braucht denn meine Möhre so lange? Das System ist neu aufgesetzt und hat eigentlich keine Besonderheiten an Board.

Hat jemand eine Idee, wenn er in den unteren Output guckt?

Code

matthias@serrano:~$ systemd-analyze
Startup finished in 10.267s (firmware) + 6.089s (loader) + 3.802s (kernel) + 21.236s (userspace) = 41.395s 
graphical.target reached after 21.209s in userspace

matthias@serrano:~$ systemd-analyze blame
13.520s vdr.service                         
 5.421s systemd-networkd-wait-online.service
 2.074s systemd-udev-settle.service         
 1.917s snap.lxd.activate.service           
 1.682s snapd.service                       
 1.409s dev-sda2.device                     
 1.247s nfs-server.service                  
  816ms systemd-logind.service              
  651ms x@vt7.service                       
  617ms udisks2.service                     
  561ms mnt-quad2\x2dbackup.mount           
  536ms networkd-dispatcher.service         
  505ms mnt-quad2\x2dgopro.mount            
  485ms lircd2uinput.service                
  476ms accounts-daemon.service             
  464ms mnt-quad2\x2dimages.mount           
  433ms mnt-quad2\x2dvideo_1.mount          
  409ms mnt-quad2\x2dmusik.mount            
  397ms mnt-quad2\x2dmovies.mount           
  359ms systemd-resolved.service            
  347ms nmbd.service                        
  338ms lircd-setup.service                 
  302ms avahi-daemon.service                
  293ms systemd-udev-trigger.service        
  284ms keyboard-setup.service              
  267ms systemd-journald.service            
  265ms user@666.service                    
  257ms lvm2-monitor.service                
  245ms user@1000.service                   
  202ms systemd-timesyncd.service           
  198ms systemd-networkd.service            
  196ms thermald.service                    
  193ms e2scrub_reap.service                
  185ms swap.img.swap                       
  182ms smbd.service                        
  173ms grub-common.service                 
  166ms dev-loop1.device                    
  165ms snap-snapd-8542.mount               
  163ms alsa-restore.service                
  163ms snap-snapd-9607.mount               
  162ms lircd.service                       
  154ms systemd-journal-flush.service       
  151ms wpa_supplicant.service              
  148ms snap-lxd-16922.mount                
  147ms secureboot-db.service               
  145ms dev-loop0.device                    
  145ms grub-initrd-fallback.service        
  123ms apport.service                      
  119ms dev-loop3.device                    
  114ms srv.mount                           
  112ms dev-loop5.device                    
  104ms rsyslog.service                     
  104ms snap-lxd-16099.mount                
   99ms nfs-mountd.service

Display More

seahawk1986 · October 17, 2020 at 9:51 PM

Mit systemd-analyze critical-chain kannst du sehen, wer da wie lange auf wen wartet.

Das größte Stück ist der VDR, vermutlich lädst du eine Menge Plugins, die in der Initialisierungsphase ordentlich ackern, bevor der VDR die Mainloop erreicht - was nutzt du denn an Plugins?

[yaVDR-Ansible] "Umfrage" Bootzeiten ...

Participate now!

Users Viewing This Thread