Leistungsabfall linux-image-3.14-3.towo-siduction-amd64

Begonnen von jackyohh, 2014/05/15, 22:56:03

Vorheriges Thema - Nächstes Thema

jackyohh

Hi,

ich hab letztens das kernelupdate von 3.13-7.towo-siduction-amd64 auf linux-image-3.14-3.towo-siduction-amd64 installiert (wegen root-bug) und mir fiel recht schnell auf, dass mein rechner danach merklich langsamer war.
ich verwende eine ssd und schon der systemstart ging verhältnismäßig träge, ebenso lief wine langsamer (ok schlechtes beispiel). ich muss dazu sagen, dass der leistungsabfall nicht extrem ist, aber doch merklich. Hat jemand ähnliches bemerkt?

dieres

#1
Ich hab hier auch seit ein paar Tagen eine nervige Verzögerung beim booten mit meiner ssd.
vorher hatte ich ne bootzeit von 14 sec vom grub Schirm bis zum stehen des XFCE Desktop.
z.Zt. pausiert die Kiste mit der systemd Auskunft das die Partition sda4 sauber wäre sage und schreibe 50 sec. bis das booten weitergeht. Danach schein dann alles normal. Hab keine Ahnung woran das liegt.

Edit: war bei mir ein eintrag in /etc/interfaces für eth0 auf meinem Laptop. Da hat er sich dann nen Wolff gesucht,wo er kein Kabel an eth0 hatte.
Nu is alles wieder gut :)

bluelupo

@dieres: kannst du da genaueres aus dem Log von systemd posten?

OppaErich

Geht mir auch so. SysV hat von HDD schneller gebootet als Systemd von SSD. Und wo versteckt die Eier legende Wollmilschsau ihre Logs ?
oppa@oppa-hex-ssd:~$ ls /var/log
alternatives.log       apt            btmp.1      cups     dmesg.0     dmesg.3.gz  dpkg.log.1     fontconfig.log  hp       libvirt    pm-powersave.log       preload.log        wtmp            Xorg.0.log
alternatives.log.1     bootstrap.log  chkrootkit  dirmngr  dmesg.1.gz  dmesg.4.gz  dpkg.log.2.gz  fsck            journal  ntpstats   pm-powersave.log.1     samba              wtmp.1          Xorg.0.log.old
alternatives.log.2.gz  btmp           ConsoleKit  dmesg    dmesg.2.gz  dpkg.log    faillog        gdm3            lastlog  partimage  pm-powersave.log.2.gz  speech-dispatcher  wvdialconf.log

devil

Zeigt doch mal jeweils ein systemd-analyze blame mit den beiden Kernen


greetz
devil

OppaErich

Ah Bindestrich, das mit analyze blame hatte ich noch im Kopf. Aber der ist wohl vom letzten Wakeup. Ich hoffe, ich habe den Kernel noch...
root@oppa-hex-ssd:~# systemd-analyze blame
          3.941s systemd-suspend.service
          1.773s dnsmasq.service

Und das ist rot in journalctl -b

...

May 12 21:26:55 oppa-hex-ssd systemd-udevd[344]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:55 oppa-hex-ssd systemd-udevd[346]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:55 oppa-hex-ssd systemd-udevd[345]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
...

May 12 21:26:56 oppa-hex-ssd systemd-udevd[462]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:56 oppa-hex-ssd systemd-udevd[464]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
...

May 12 21:26:56 oppa-hex-ssd systemd-udevd[461]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:56 oppa-hex-ssd kernel: [drm] ring test on 0 succeeded in 1 usecs
May 12 21:26:56 oppa-hex-ssd kernel: [drm] ring test on 3 succeeded in 1 usecs
May 12 21:26:56 oppa-hex-ssd systemd-udevd[480]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
...

May 12 21:26:58 oppa-hex-ssd libvirtd[979]: libvirt version: 1.2.4
May 12 21:26:58 oppa-hex-ssd libvirtd[979]: direct firewall backend requested, but /sbin/ebtables is not available: No such file or directory
...

May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 0.debian.pool.ntp.org
May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 1.debian.pool.ntp.org
May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 2.debian.pool.ntp.org
May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 3.debian.pool.ntp.org
...

May 12 21:41:52 oppa-hex-ssd systemd[1]: Starting Cleanup of Temporary Directories...
May 12 21:41:52 oppa-hex-ssd systemd-tmpfiles[22496]: stat(/run/user/1000/gvfs) failed: Permission denied
May 12 21:41:52 oppa-hex-ssd systemd[1]: Started Cleanup of Temporary Directories.

Hmm, außer der Pause beim Booten fühlt sich alles Gesund an.

OppaErich

So, das ist der älteste Kernel den ich noch habe. Alles im Sub-Sekunden Bereich habe ich weggelassen. udev scheint ein wenig zu brauchen.
root@oppa-hex-ssd:~# systemd-analyze blame
         30.278s systemd-udev-settle.service 
          1.365s systemd-fsck-root.service
          1.079s acpi-fakekey.service
           529ms virtualbox.service
         
...

root@oppa-hex-ssd:~# uname -r
3.13-7.towo-siduction-amd64

pit

Hast du nfs-Shares gemountet?

Ich beobachte hier ähnliches. Während des Bootens erscheint zunächst beispielsweise:

systemd-fsck[690]: /dev/sdb8: sauber, 1520/9969664 Dateien, 6264458/39847216 Blöcke
systemd-fsck[703]: /dev/sdb5: sauber, 440/5238560 Dateien, 15441384/20972849 Blöcke
systemd-fsck[690]: linuxdata: sauber, 713/5242880 Dateien, 8659835/20971519 Blöcke
systemd-fsck[710]: linuxhome: sauber, 69386/1310720 Dateien, 2499914/5242880 Blöcke


Danach mitunter ziemlich lange Pause, dann geht's weiter.

Ich vermute, dass einige Einträge in meiner /etc/fstab schuld sind. Mein NAS (Synology DS 212+) stellt einige nfs Shares zur Verfügung, die ich via fstab mounte. Entsprechende Einträge bekamen mit dem Umstieg auf systemd eine andere Syntax:

nas:/volume1/photo  /media/nasphoto  nfs  noauto,x-systemd.automount,x-systemd.device-timeout=10,defaults  0  0

Ein Reboot ist wesenlich schneller, wenn ich diese fstab-Einträge auskommentiere. Irgendwie blöd und ganz klar ein Komfortverlust. Eine andere Lösung habe ich noch nicht gefunden. Irgendwo las ich was über automount, da habe ich mich aber noch nicht reingefuchst.

/edit

$ systemd-analyze blame
         30.468s systemd-udev-settle.service
          1.037s acpi-fakekey.service
           757ms acpi-support.service
           606ms loadcpufreq.service
           603ms ModemManager.service
           590ms systemd-fsck@dev-disk-by\x2duuid-3a0c2dec\x2de3d2\x2d4672\x2daba1\x2d292333668013.service
           515ms bootlogs.service
           506ms systemd-fsck@dev-disk-by\x2duuid-14f17913\x2d5850\x2d440c\x2d8590\x2d2836dcf47bc4.service
           499ms systemd-fsck@dev-disk-by\x2duuid-a8f2e75d\x2d36c2\x2d4578\x2db318\x2db8549ab65d05.service
           497ms systemd-fsck-root.service
           462ms systemd-fsck@dev-disk-by\x2duuid-6d0971d7\x2de467\x2d4254\x2d9fba\x2d46c46d39bf47.service
           249ms dev-disk-by\x2duuid-6383399e\x2d45c3\x2d459e\x2da010\x2dd808dbf97481.swap

bluelupo

Hi,
mit den nfs-Shares habe ich kein Problem, d.h. sie werden auch nicht langsamer abgearbeitet als wie vorher.


# NFS-Mounts NAS Synology DS211
diskstation:/volume1/Exchange             /mnt/import/dataexchange   nfs   rw,noauto,users,x-systemd.automount,vers=3      0    0
diskstation:/volume1/VM                   /mnt/import/vm             nfs   rw,noauto,users,x-systemd.automount,vers=3      0    0
diskstation:/volume1/Backup_Diskimages    /mnt/import/diskdump       nfs   rw,noauto,users,x-systemd.automount,vers=3      0    0
diskstation:/volume2/Backup_Filesnapshots /mnt/import/rsnapshot      nfs   rw,noauto,users,x-systemd.automount,vers=3      0    0
diskstation:/volume2/Backup_Archive       /mnt/import/archive        nfs   rw,noauto,users,x-systemd.automount,vers=3      0    0


Bewegt sich alles "normalen" Bereich.

# systemd-analyze blame|grep nfs
           108ms nfs-kernel-server.service
            82ms nfs-common.service

pit

@BlueLupo: Auffällig ist halt, dass es hier mit aktiviertem fstab-Eintrag heftige Pausen hat, auskommentiert geht's fix.

Was es mit dem 30 Sekunden benötigenden systemd-udev-settle.service (s.o.) auf sich hat, weiß ich nicht. @OppaErich berichtet in diesem Thread ähnliches.

Wenn ich via systemd-analyze blame nach nfs greppe, bekomme ich ein recht ähnliches Ergebnis wie deins.

bluelupo

#10
@pit: ist dein NAS vielleicht im Ruhezustand (Platten abgeschaltet) gewesen?

So schauts bei mir aus:

# systemd-analyze blame|grep systemd-udev-settle.service
          1.220s systemd-udev-settle.service

devil

Mit dem Parameter x-systemd.device-timeout=10 kann man spielen/weglassen/kürzen.


greetz
devil

pit

#12
D.h., zwischen meinem fstab-Eintrag u. dieser Meldung gibt es einen Zusammenhang?
5.176s systemd-udev-settle.service
Sieht auf jeden Fall jetzt besser aus. Habe in der fstab auf 500ms reduziert.

OppaErich

fstab ? Spielt der mit Partitionen rum die gar nicht gemounted werden sollen ?
root@oppa-hex-ssd:~# cat /etc/fstab
UUID=507AB7337AB71526                         /media/disk1part1    ntfs         noauto,users,ro,dmask=0022,fmask=0133,nls=utf8  0    0   
UUID=46844C6B844C5F93                         /media/disk1part2    ntfs         noauto,users,ro,dmask=0022,fmask=0133,nls=utf8  0    0   
UUID=40529CF71C3D6D3D                         /media/disk1part3    ntfs         noauto,users,ro,dmask=0022,fmask=0133,nls=utf8  0    0   
UUID=f92a89dc-1a40-46d6-a228-4e90e2206a5c     /media/disk1part5    ext4         noauto,users,rw,exec,relatime                   0    0   
UUID=94f3f15c-2a10-4bdd-81e0-7fb0ba7a9f89     /media/disk1part6    ext4         noauto,users,rw,exec,relatime                   0    0   
UUID=1138dfcf-3e8b-4880-999f-b8a8381b3b1b     /media/disk1part7    ext4         noauto,users,rw,exec,relatime                   0    0   
UUID=9e040c55-ffe5-4e81-a27e-dd02e01264dd     none                 swap         sw                                            0    0   
UUID=40529CF71C3D6D3D                         /media/disk2part1    ntfs         noauto,users,ro,dmask=0022,fmask=0133,nls=utf8  0    0   
UUID=3b851ea5-2726-4cca-9d28-f2ea725f03e2     /                    ext4         discard,noatime,commit=600,defaults,errors=remount-ro           0    1   

bluelupo

Hi OppaErich,
nimm die Mountpoints /media/disk?part? alle raus, wenn du sie nicht benötigst. Wenn du einzelne benötigst würde ich mir aussagekräftigere Einhängpunkte unter /media oder /mnt erstellen.