[gelöst][0.5-alpha] Hohe CPU-Last des vdr Prozesses...

mini73 · 15. Juni 2012

Moin!

Zwei dbus-Prozesse sind in Ordnung, der eine ist der System-Bus, der andere der Session-Bus des Benutzers 102 (messagebus).

Was passiert denn, wenn ihr "svdrpsend plug softhddevice DETA" ausführt? Geht dann die Auslastung auch runter? Geht sie wieder hoch bei "svdrpsend plug softhddevice ATTA -d :1"?
Ich hatte hier beim Testen manchmal das Problem, dass softhddevice eine hohe Auslastung hatte.
Wenn dbus2vdr nicht geladen wird, kann die Ausgabe nicht aktiviert werden und damit verschwindet auch die Auslastung.

Aber trotzdem besteht eine hohe Wahrscheinlichkeit, dass dbus2vdr da noch irgendwas macht, womit es in einigen Situationen Probleme gibt.

Statt dbus abzuschießen, könntet ihr auch einfach mal ein "sudo restart dbus" versuchen.

Wie ermittelt ihr die Thread-IDs? Und stimmen die wirklich mit den IDs der vdr-Threads überein?

Lars.

ofenheizer · 15. Juni 2012

Zitat von mini73

Was passiert denn, wenn ihr "svdrpsend plug softhddevice DETA" ausführt? Geht dann die Auslastung auch runter? Geht sie wieder hoch bei "svdrpsend plug softhddevice ATTA -d :1"?

mein betroffener vdr benutzt xineliboutput.

ofenheizer · 15. Juni 2012

Zitat von mini73

Statt dbus abzuschießen, könntet ihr auch einfach mal ein "sudo restart dbus" versuchen.

das hat geholfen, cpu-last von 98% runter auf 3%
hier das log vom restart

Code

Jun 15 17:59:41 vdrmp vdr: [1520] dbus2vdr: new message, object /org/freedesktop/DBus/Local, interface org.freedesktop.DBus.Local, member Disconnected
Jun 15 17:59:41 vdrmp vdr: [1520] dbus2vdr: disconnected from system bus, will try to reconnect
Jun 15 17:59:41 vdrmp vdr: [1520] dbus2vdr: try to reconnect to system bus
Jun 15 17:59:41 vdrmp vdr: [1520] dbus2vdr: connection error: Failed to connect to socket /var/run/dbus/system_bus_socket: Datei oder Verzeichnis nicht gefunden
Jun 15 17:59:41 vdrmp vdr: [1746] dbus2vdr: emit upstart-signal vdr-plugin for started
Jun 15 17:59:42 vdrmp vdr: [1520] dbus2vdr: try to reconnect to system bus
Jun 15 17:59:42 vdrmp vdr: [1520] dbus2vdr: reconnect to system bus successful
Jun 15 17:59:43 vdrmp vdr: [1520] dbus2vdr: new message, object /org/freedesktop/DBus, interface org.freedesktop.DBus, member NameAcquired
Jun 15 17:59:43 vdrmp vdr: [1520] dbus2vdr: NameAcquired: get ownership of name :1.3
Jun 15 17:59:43 vdrmp vdr: [1520] dbus2vdr: new message, object /org/freedesktop/DBus, interface org.freedesktop.DBus, member NameAcquired
Jun 15 17:59:43 vdrmp vdr: [1520] dbus2vdr: NameAcquired: get ownership of name de.tvdr.vdr

Alles anzeigen

installierte dbus2vdr-version ist aktuell noch diese

Code

ii  vdr-plugin-dbus2vdr                20120609162227unstable-0yavdr0~precise                            A VDR plugin, control VDR via DBus

gruss.
markus

BooStar · 15. Juni 2012

Hallo ich habe das grade mal gegen geprüft,
wenn ich "restart dbus" eingebe sind die CPU-Last auf normal..
getestet mit

Code

vdr-plugin-dbus2vdr                  20120530214259testing-0yavdr0~precise

hotzenplotz5 · 15. Juni 2012

habt ihr zufällig eine usb festplatte angestöpselt ?
mit aufnahemen ?

BooStar · 15. Juni 2012

Hallo..
nein, bei mir hängt am usb nur der yaUSBir..

klausL · 15. Juni 2012

Hallo,

der restart dbus funktioniert auch bei mir zuverlässig.
Ich habe nichts am USB hängen (außer manchmal ne Tastatur).

Hier auch noch mein Log ab dem "restart dbus". Der avahi-daemon muss sich wohl auch neu sortieren. Zwischendrin (Zeile 13) gibt es mal einen connection error.

Code

Jun 15 20:55:48 VDR avahi-daemon[4026]: Disconnected from D-Bus, exiting.
Jun 15 20:55:48 VDR avahi-daemon[4026]: Got SIGTERM, quitting.
Jun 15 20:55:48 VDR avahi-daemon[4026]: Leaving mDNS multicast group on interface eth0.IPv6 with address 2002:57a7:acb6:0:226:18ff:fee7:ab9.
Jun 15 20:55:48 VDR avahi-daemon[4026]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.0.1.8.
Jun 15 20:55:48 VDR kernel: [ 5281.560810] init: Disconnected from system bus
Jun 15 20:55:48 VDR kernel: [ 5281.561430] init: avahi-mounter main process (4017) terminated with status 1
Jun 15 20:55:48 VDR kernel: [ 5281.561449] init: avahi-mounter main process ended, respawning
Jun 15 20:55:48 VDR avahi-daemon[4026]: avahi-daemon 0.6.30 exiting.
Jun 15 20:55:48 VDR vdr: [7264] dbus2vdr: new message, object /org/freedesktop/DBus/Local, interface org.freedesktop.DBus.Local, member Disconnected
Jun 15 20:55:48 VDR vdr: [7264] dbus2vdr: disconnected from system bus, will try to reconnect
Jun 15 20:55:48 VDR kernel: [ 5281.570036] init: avahi-daemon main process ended, respawning
Jun 15 20:55:48 VDR vdr: [7264] dbus2vdr: try to reconnect to system bus
Jun 15 20:55:48 VDR vdr: [7264] dbus2vdr: connection error: Failed to connect to socket /var/run/dbus/system_bus_socket: Datei oder Verzeichnis nicht gefunden
Jun 15 20:55:48 VDR vdr: [7295] dbus2vdr: emit upstart-signal vdr-plugin for started
Jun 15 20:55:48 VDR kernel: [ 5281.583248] init: avahi-mounter main process (7969) killed by TERM signal
Jun 15 20:55:48 VDR kernel: [ 5281.614754] init: plymouth-upstart-bridge main process (7982) terminated with status 1
Jun 15 20:55:48 VDR avahi-daemon[7985]: Found user 'avahi' (UID 103) and group 'avahi' (GID 108).
Jun 15 20:55:48 VDR avahi-daemon[7985]: Successfully dropped root privileges.
Jun 15 20:55:48 VDR avahi-daemon[7985]: avahi-daemon 0.6.30 starting up.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Successfully called chroot().
Jun 15 20:55:48 VDR avahi-daemon[7985]: Successfully dropped remaining capabilities.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Loading service file /services/udisks.service.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Loading service file /services/vdr-audio.service.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Loading service file /services/vdr-picture.service.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Loading service file /services/vdr-svdrp.service.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Loading service file /services/vdr-vdr.service.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Loading service file /services/vdr-video.service.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Joining mDNS multicast group on interface eth0.IPv6 with address 2002:57a7:acb6:0:226:18ff:fee7:ab9.
Jun 15 20:55:48 VDR avahi-daemon[7985]: New relevant interface eth0.IPv6 for mDNS.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.1.8.
Jun 15 20:55:48 VDR avahi-daemon[7985]: New relevant interface eth0.IPv4 for mDNS.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Network interface enumeration completed.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Registering new address record for 2002:57a7:9d26:0:226:18ff:fee7:ab9 on eth0.*.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Registering new address record for 2002:57a7:9d26:0:6883:a863:5ced:8380 on eth0.*.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Registering new address record for 10.0.1.8 on eth0.IPv4.
Jun 15 20:55:48 VDR avahi-daemon[7985]: Registering HINFO record with values 'X86_64'/'LINUX'.
Jun 15 20:55:48 VDR avahi-mounter[7976]: mount static to /srv/vdr/video.00
Jun 15 20:55:48 VDR avahi-mounter[7976]: initialized zeroconf browser on VDR
Jun 15 20:55:48 VDR avahi-mounter[7976]: Resolved type _nfs._tcp on MacMini.local
Jun 15 20:55:48 VDR avahi-mounter[7976]: ERROR: coercing to Unicode: need string or buffer, list found
Jun 15 20:55:48 VDR avahi-mounter[7976]: Service resolved: MacMini.local to MacMini
Jun 15 20:55:48 VDR avahi-mounter[7976]: Resolved type _nfs._tcp on MacMini.local
Jun 15 20:55:48 VDR avahi-mounter[7976]: ERROR: coercing to Unicode: need string or buffer, list found
Jun 15 20:55:48 VDR avahi-mounter[7976]: Service resolved: MacMini.local to MacMini
Jun 15 20:55:49 VDR avahi-daemon[7985]: Server startup complete. Host name is VDR.local. Local service cookie is 4051350998.
Jun 15 20:55:49 VDR vdr: [7264] dbus2vdr: try to reconnect to system bus
Jun 15 20:55:49 VDR vdr: [7264] dbus2vdr: reconnect to system bus successful
Jun 15 20:55:49 VDR avahi-daemon[7985]: Service "Videos on VDR" (/services/vdr-video.service) successfully established.
Jun 15 20:55:49 VDR avahi-daemon[7985]: Service "Recordings on VDR" (/services/vdr-vdr.service) successfully established.
Jun 15 20:55:49 VDR avahi-daemon[7985]: Service "SVDRP on VDR" (/services/vdr-svdrp.service) successfully established.
Jun 15 20:55:49 VDR avahi-daemon[7985]: Service "Pictures on VDR" (/services/vdr-picture.service) successfully established.
Jun 15 20:55:49 VDR avahi-daemon[7985]: Service "Music on VDR" (/services/vdr-audio.service) successfully established.
Jun 15 20:55:49 VDR avahi-daemon[7985]: Service "VDR" (/services/udisks.service) successfully established.
Jun 15 20:55:49 VDR avahi-mounter[7976]: Resolved type _nfs._tcp on VDR.local
Jun 15 20:55:50  avahi-mounter[7976]: last message repeated 7 times
Jun 15 20:55:50 VDR vdr: [7264] dbus2vdr: new message, object /org/freedesktop/DBus, interface org.freedesktop.DBus, member NameAcquired
Jun 15 20:55:50 VDR vdr: [7264] dbus2vdr: NameAcquired: get ownership of name :1.3
Jun 15 20:55:50 VDR vdr: [7264] dbus2vdr: new message, object /org/freedesktop/DBus, interface org.freedesktop.DBus, member NameAcquired
Jun 15 20:55:50 VDR vdr: [7264] dbus2vdr: NameAcquired: get ownership of name de.tvdr.vdr

Alles anzeigen

Die Threads sieht man übrigens sehr schön mit den Tool htop, mittels F5 dann in die Tree-Ansicht gewechselt. Dort ist dann auch pro Rgread die CPU-Auslastung ablesbar. Fast so schön sind sie auch mit ps ax -T zu sehen.

Klaus

mini73 · 15. Juni 2012

Moin!

Benutzt ihr SSDs für das System? Naja, jedenfalls scheint es sich abzuzeichnen, dass beim Booten die Kommunikation zwischen Plugin und dbus-daemon irgendwie noch nicht klappt.
So als ob beide noch nicht ganz bereit sind.

Dabei wartet vdr eigentlich auf dbus. Steffen hatte da auch ein komisches Problem, wo ein vdr-dbus-send zu früh abgesendet wird, obwohl alle eigentlich erst nach dem vdr aufgerufen werden.
Deshalb hatten wir die dbus-activation eingebaut, so dass der vdr beim ersten vdr-dbus-send gestartet wird.

Könnte also "nur" eine komische (Nicht-)Abhängigkeit innerhalb der Upstart-Scripte sein. Irgendwie starten die zu sehr parallel oder so.
Ich hab jedenfalls einen Ansatzpunkt, nächste Woche werde ich mir das ansehen.

Lars.

klausL · 15. Juni 2012

Bei mir liegt /boot auf einem SATA-Flashmodul, / auf Festplatte in einem LVM-Volume, /srv ebenfalls auf Platte in einem LVM-Volume.

Klaus

ofenheizer · 16. Juni 2012

Am betreffenden VDR meiner Eltern, hängt ab und zu mal eine USB-Platte, aber auch ohne die ga es die hohe CPU-Last. Dauerhaft am USB hängen nur ein Smargo und das Display samt FB des Antec-Gehäuses. Eine SSD ist auch nicht vorhanden, es gibt nur eine Festplatte im System.

BooStar · 16. Juni 2012

Hallo...

Zitat

Benutzt ihr SSDs für das System?

Nein, ich benutze eine 2,5" Platte mit 5400rpm.

Zitat

Naja, jedenfalls scheint es sich abzuzeichnen, dass beim Booten die
Kommunikation zwischen Plugin und dbus-daemon irgendwie noch nicht
klappt.

Ich habe gestern noch zwei Installationen in virutellen Maschinen angestoßen.
Einmal von USB-Sick installiert, also vorher mit dem Startmedienersteller bearbeitet und einmal direkt vom ISO, kein unterschied zum VDR aus meiner Sig, also CPU-Last hoch..
Ich hatte dafür die komplette Festplatte als Installationsziel ausgewählt.

Zitat

habt ihr zufällig eine usb festplatte angestöpselt ?

Bei mir hängt nichts am USB, außer eben dem yaUSBir, auch wenn ich den entferne ist die CPU-Last hoch..

Zitat

Ich hab jedenfalls einen Ansatzpunkt, nächste Woche werde ich mir das ansehen.

Das ist doch schonmal gut, oder auch nicht Ich freue mich jedenfalls das du dich der Sache annimmst, ich bin nämlich langsam mit meinem Latein am Ende...
Vielen Dank für eure Hilfe...
Boo

steffen_b · 16. Juni 2012

Vielleicht könnten die Leute, welche das Problem haben folgendes Testen:

In Zeile 43 folgendes auskommentieren:
$TARGET_GOAL $WAIT_FOR :

also
# $TARGET_GOAL $WAIT_FOR :

danach einmal/mehrmals rebooten und hier berichten ob es das Verhalten verändert.

BooStar · 16. Juni 2012

in welcher datei denn?
//edit: /etc/init/wait-for-state.conf

BooStar · 16. Juni 2012

so,
eben geprüft, 5xreboot keine besserung, der vdr-prozess ist immer bei 95%

steffen_b · 16. Juni 2012

Genau - bin wohl noch nicht wach genug

gda · 16. Juni 2012

Könnte eventuell ein Bootchart helfen zu erkennen was denn anders als bei uns läuft?

Gerald

BooStar · 16. Juni 2012

sowas hier:
https://www.dropbox.com/sh/0eprohjhm5euqve/Dhu86CUdRX

steffen_b · 16. Juni 2012

Was man schonmal sieht, ist das es kein Timing Problem zwischen dbus daemon und dbus2vdr sein kann. Es scheint aber das dbus-send zu hängen (20s ca.)

klausL · 16. Juni 2012

Hallo,

bei mir hat die Änderung in der wake-for-state.conf auch keine Besserung gebracht.

Mein Bootchart steht hier :
Ab dem vdr-dbus-send und dbus-send (und gleichzeitigem Start des sshd) bleibt die CPU-Auslastung oben.

Klaus

klausL · 17. Juni 2012

Hallo,

ich habe gerade noch etwas gesehen:
Gleich nach der Installation der 0.5 hat htop schon mal die 100% Auslastung angezeigt. Damals war mir aufgefallen, dass der irserver alle paar Sekunden mal kurz die CPU mit über 80 % auslastet. Nach Lesen in der yavdr-Doku hatte ich den Eindruck, dass ich den irserver nicht brauche, weil ich einen Atric mit lircd für die Fernbedienung verwende, und habe den irserver lahmgelegt (die "start on"-Zeile auskommentiert).
Mit dem heutigen Update war auch was mit dem irserver dabei. Da fiel mir die auskommentierte Zeile ein und ich habe sie mal wieder aktiviert.
Das Ergebnis: Alle 5 Sekunden startet der irserver und beendet sich wieder.
Im syslog:

Code

Jun 17 22:40:12 VDR kernel: [40046.434097] init: irserver main process (11552) terminated with status 255
Jun 17 22:40:12 VDR kernel: [40046.434123] init: irserver main process ended, respawning

htop zeigt dabei durchgehend 100% CPU-Auslastung an.
Nach einem "restart dbus" zeigen die VDR-Threads keine hohe CPU-Belastung mehr (wie bereits bekannt), aber die angezeigte CPU-Auslastung ist immer noch 100 %.
Nach einem "stop irserver" ist die Last direkt wieder unten bei 16 %. Meine Fernbedienung geht natürlich trotzdem.
Damit wäre zumindest eine zweite Möglichkeit da, die die CPU-Auslastung hochtreibt. Ob es eine gemeinsame Ursache gibt, kann ich nicht erkennen.

Klaus

[gelöst][0.5-alpha] Hohe CPU-Last des vdr Prozesses...

Jetzt mitmachen!

Teilen