Moin,
habe gerade die 0.5 installiert und hatte ebenfalls eine hohe CPU-Auslastung von bis zu 99%.
Nach dem Aendern der Audio-Einstellungen von 'Ausgabe an allen Geräten' nach 'HDMI-Passthrough'
passts dann mit der Auslastung, liegt nun bei 2%.
Also hier das altbekannte Problem mit alsa .
mfg
[gelöst][0.5-alpha] Hohe CPU-Last des vdr Prozesses...
-
-
Nabend,
habe ein yavdr 0.5 headless System mit 98% vdr Auslastung.
Da bringt ein ändern der Audio-Einstellungen nix.Bei jeder Einstellung ist die Last so hoch...
Munter bleiben, Rossi
-
Moin!
Würd' mich freuen, wenn das zur "Erhellung" beiträgt.
Siehst du danach noch sowas wie:
oder irgendwas anderes mit "dbus2vdr"?Was passiert, wenn in /etc/init/vdr.conf die Zeile mit dbus-activation entfernt wird?
Lars.
-
Hallo mini73,
ich sehe keine weiteren Logmeldungen mit dbus-Bezug. Ein "can't emit upstart signal" war nicht im syslog, ebenso wenig noch andere Meldungen. Ich habe noch mal gecheckt, aber es waren alle Meldungen zu dbus und dbus2vdr in meinem Beitrag.
Wenn ich in der /etc/init/vdr.conf unter "start on" die Zeile "(dbus-activation de.tvdr.vdr and startup) or \" rauslösche, ändert sich am VDR-Verhalten bei einem Systemneustart nichts. Es funktioniert alles wie gehabt einschließlich der 100% CPU.
KlausL
-
Moin!
Schon merkwürdig... Ich hab aber mal das Connection-Handling etwas überarbeitet. Momentan baut das Paket noch in unstable, aber sobald es fertig ist, könntest du es ja mal manuell einspielen und testen, was dann passiert.
Ich hoffe auch, dass die Logmeldungen aussagekräftiger werden.Lars.
-
Hi mini73,
ZitatSchon merkwürdig... Ich hab aber mal das Connection-Handling etwas
überarbeitet. Momentan baut das Paket noch in unstable, aber sobald es
fertig ist, könntest du es ja mal manuell einspielen und testen, was
dann passiert.Ich hoffe auch, dass die Logmeldungen aussagekräftiger werden.
Vielen Dank dafür, leider habe ich diese Woche sehr wenig Zeit, sonst würde ich das Paket sofort testen, aber leider komme ich wohl erst am Wochenende dazu...
-
Moin!
Schon merkwürdig... Ich hab aber mal das Connection-Handling etwas überarbeitet. Momentan baut das Paket noch in unstable, aber sobald es fertig ist, könntest du es ja mal manuell einspielen und testen, was dann passiert.
Ich hoffe auch, dass die Logmeldungen aussagekräftiger werden.Lars.
Dann schau ich mal heute abend, ob ich Zugriff bekomme und update das Paket mal.Gruss
Markus -
Moin!
aber leider komme ich wohl erst am Wochenende dazu...
Keine Eile...Dann schau ich mal heute abend, ob ich Zugriff bekomme und update das Paket mal.
Prima!Ich beschäftige mich im Schnitt nur einen Abend pro Woche mit dem vdr, ich erwarte kein schnelleres Tempo.
Lars.
-
Zitat
Ich beschäftige mich im Schnitt nur einen Abend pro Woche mit dem vdr, ich erwarte kein schnelleres Tempo
Trotzdem vielen Dank für deine Hilfe, ich denke die können wir hier gut gebrauchen...
-
Moin!
Trotzdem vielen Dank für deine Hilfe, ich denke die können wir hier gut gebrauchen...
Kein Problem, wenn ich Mist verzapfe, räum ich auch gerne auf.Lars.
-
Hallo,
ich habe die Version aus unstable mal installiert und damit den vdr neu gestartet. Die CPU-Auslastung ist unverändert, aber es kommen ein paar mehr Logmeldungen.
Alle Logmeldungen beim Starten des vdr (ab Plugin-Start):
Code
Alles anzeigenJun 14 15:30:30 VDR vdr: [2613] starting plugin: dbus2vdr Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.epg Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.osd Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.plugin Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.recording Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.remote Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.setup Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.shutdown Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.skin Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new message dispatcher for interface de.tvdr.vdr.timer Jun 14 15:30:30 VDR vdr: [2678] VDR XVDR Server thread started (pid=2613, tid=2678) Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: monitor started on bus de.tvdr.vdr Jun 14 15:30:30 VDR vdr: [2677] extrecmenu worker thread thread started (pid=2613, tid=2677) Jun 14 15:30:30 VDR vdr: [2675] EPGSearch: conflictcheck thread started (pid=2613, tid=2675) Jun 14 15:30:30 VDR vdr: [2674] streamdev server thread started (pid=2613, tid=2674) Jun 14 15:30:30 VDR vdr: [2674] Streamdev: Listening (VTP) on port 2004 Jun 14 15:30:30 VDR vdr: [2674] Streamdev: Listening (HTTP) on port 3000 Jun 14 15:30:30 VDR vdr: [2673] targaVFD: watch thread thread started (pid=2613, tid=2673) Jun 14 15:30:30 VDR vdr: [2613] starting plugin: live Jun 14 15:30:30 VDR vdr: [2613] LIVE: initial file cache has 82 entries and needs 377394 bytes of data! Jun 14 15:30:30 VDR vdr: [2613] starting plugin: dynamite Jun 14 15:30:30 VDR vdr: [2613] dynamite: startup channel is 2 Jun 14 15:30:30 VDR vdr: [2613] setting current skin to "NarrowHD" Jun 14 15:30:30 VDR vdr: [2613] loading /var/lib/vdr/themes/NarrowHD-default.theme Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: try to connect to system bus Jun 14 15:30:30 VDR vdr: [2613] remote control LIRC - keys known Jun 14 15:30:30 VDR vdr: [2613] switching to channel 2 Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: connect to system bus successful Jun 14 15:30:30 VDR vdr: [2687] LIRC remote control thread started (pid=2613, tid=2687) Jun 14 15:30:30 VDR vdr: [2686] [live] INFO: attempt to listen on ip = '0.0.0.0' Jun 14 15:30:30 VDR vdr: [2686] [live] ERROR: Unable to load cert/key (/var/lib/vdr/plugins/live/live.pem//var/lib/vdr/plugins/live/live-key.pem): Datei oder Verzeichnis nicht gefunden Jun 14 15:30:30 VDR vdr: [2688] receiver on device 1 thread started (pid=2613, tid=2688) Jun 14 15:30:30 VDR vdr: [2689] TS buffer on device 1 thread started (pid=2613, tid=2689) Jun 14 15:30:30 VDR vdr: [2668] epg data reader thread ended (pid=2613, tid=2668) Jun 14 15:30:30 VDR vdr: [2613] [softhddev]SetVolumeDevice: 255 Jun 14 15:30:30 VDR vdr: [2613] [softhddev]SetPlayMode: 1 Jun 14 15:30:30 VDR vdr: [2613] OSD size changed to 1920x1080 @ 1 Jun 14 15:30:30 VDR vdr: [2697] Text2Skin: channelInfo display update thread started (pid=2613, tid=2697) Jun 14 15:30:30 VDR vdr: [2697] [softhddev]Flush: FIXME: should be truecolor Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: raise SIGSTOP for Upstart Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: new DBus-Upstart-Signal-Sender Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: emit upstart-signal started for all plugins Jun 14 15:30:30 VDR vdr: [2613] dbus2vdr: upstart-signal started queued Jun 14 15:30:30 VDR vdr: [2700] dbus2vdr: DBus-Upstart-Signal-Sender thread started (pid=2613, tid=2700) Jun 14 15:30:30 VDR vdr: [2700] dbus2vdr: dequeue signal vdr-plugin/started Jun 14 15:30:30 VDR vdr: [2700] dbus2vdr: retrieving connection for sending signal Jun 14 15:30:30 VDR vdr: [2700] dbus2vdr: retrieving connection for sending signal (waiting/1) Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: new message, object /org/freedesktop/DBus, interface org.freedesktop.DBus, member NameAcquired Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: NameAcquired: get ownership of name :1.27 Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: new message, object /org/freedesktop/DBus, interface org.freedesktop.DBus, member NameAcquired Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: NameAcquired: get ownership of name de.tvdr.vdr Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: new message, object /Plugins/softhddevice, interface de.tvdr.vdr.plugin, member SVDRPCommand Jun 14 15:30:30 VDR vdr: [2679] dbus2vdr: starting new message handler 0x7f3120001a60 Jun 14 15:30:30 VDR vdr: [2718] dbus2vdr message handler thread started (pid=2613, tid=2718) Jun 14 15:30:30 VDR vdr: [2718] dbus2vdr: invoking softhddevice.SVDRPCommand("ATTA", "-d :1") Jun 14 15:30:30 VDR vdr: video/vdpau: VDPAU API version: 1 Jun 14 15:30:30 VDR vdr: video/vdpau: VDPAU information: NVIDIA VDPAU Driver Shared Library 295.40 Thu Apr 5 22:02:06 PDT 2012 Jun 14 15:30:30 VDR vdr: video/vdpau: high quality scaling unsupported Jun 14 15:30:30 VDR vdr: video/vdpau: feature deinterlace temporal supported Jun 14 15:30:30 VDR vdr: video/vdpau: feature deinterlace temporal spatial supported Jun 14 15:30:30 VDR vdr: video/vdpau: attribute skip chroma deinterlace supported Jun 14 15:30:30 VDR vdr: video/vdpau: 4:2:0 chroma format with 4096x4096 supported Jun 14 15:30:30 VDR vdr: video/vdpau: 4:2:2 chroma format with 4096x4096 supported Jun 14 15:30:30 VDR vdr: video/vdpau: 8bit BGRA format with 8192x8192 supported Jun 14 15:30:30 VDR vdr: video/vdpau: 10bit RGBA format with 8192x8192 supported Jun 14 15:30:30 VDR vdr: audio: 'alsa' output module used Jun 14 15:30:30 VDR vdr: audio/alsa: supports pause: yes Jun 14 15:30:30 VDR vdr: audio: 44100Hz supports 2 2 8 8 8 8 8 8 channels Jun 14 15:30:30 VDR vdr: audio: 48000Hz supports 2 2 8 8 8 8 8 8 channels Jun 14 15:30:30 VDR vdr: [2718] dbus2vdr: moving message handler 0x7f3120001a60 from active to finished Jun 14 15:30:30 VDR vdr: [2718] dbus2vdr message handler thread ended (pid=2613, tid=2718) Jun 14 15:30:30 VDR vdr: audio/alsa: using device 'default' Jun 14 15:30:30 VDR vdr: audio/alsa: start delay 336ms Jun 14 15:30:31 VDR vdr: [2675] EPGSearch: timer conflict check started Jun 14 15:30:31 VDR vdr: [2675] EPGSearch: timer conflict check finished Jun 14 15:30:31 VDR vdr: video/vdpau: missed frame (1/7) Jun 14 15:30:32 VDR vdr: video: decoder buffer empty, duping frame (1/29) 0 v-buf Jun 14 15:30:32 VDR vdr: video: 6:20:44.966+8888 0 0/\ms 0 v-buf Jun 14 15:30:35 VDR vdr: [2697] Text2Skin: channelInfo display update thread ended (pid=2613, tid=2697)
Der Thread 2700 ist derjenige, dem die CPU-Auslastung zugeordnet ist.
Während der Laufzeit und einem Stop des vdr kommt dann (hier wieder alle Logmeldungen, nicht nur die vom Plugin):
Code
Alles anzeigenJun 14 15:41:31 VDR vdr: [2679] dbus2vdr: new message, object /Plugins/softhddevice, interface de.tvdr.vdr.plugin, member SVDRPCommand Jun 14 15:41:31 VDR vdr: [2679] dbus2vdr: 1 idle message handler, reusing 0x7f3120001a60 Jun 14 15:41:31 VDR vdr: [2892] dbus2vdr message handler thread started (pid=2613, tid=2892) Jun 14 15:41:31 VDR vdr: [2892] dbus2vdr: de.tvdr.vdr.plugin.SVDRPCommand: command 'DETA' has no option Jun 14 15:41:31 VDR vdr: [2892] dbus2vdr: invoking softhddevice.SVDRPCommand("DETA", "") Jun 14 15:41:31 VDR vdr: [2892] [softhddev]SetPlayMode: 0 Jun 14 15:41:31 VDR vdr: [2892] [softhddev]SetVideoDisplayFormat: 1 Jun 14 15:41:31 VDR vdr: [2892] [softhddev]SetPlayMode: 1 Jun 14 15:41:31 VDR vdr: [2689] TS buffer on device 1 thread ended (pid=2613, tid=2689) Jun 14 15:41:31 VDR vdr: [2688] buffer stats: 359456 (17%) used Jun 14 15:41:31 VDR vdr: [2688] receiver on device 1 thread ended (pid=2613, tid=2688) Jun 14 15:41:31 VDR vdr: [2892] dbus2vdr: moving message handler 0x7f3120001a60 from active to finished Jun 14 15:41:31 VDR vdr: [2892] dbus2vdr message handler thread ended (pid=2613, tid=2892) Jun 14 15:41:33 VDR vdr: [2613] stopping plugin: dynamite Jun 14 15:41:33 VDR vdr: [2613] dynamite: force detaching all devices Jun 14 15:41:33 VDR vdr: [2613] stopping plugin: live Jun 14 15:41:33 VDR vdr: [2613] stopping plugin: dbus2vdr Jun 14 15:41:33 VDR vdr: [2613] dbus2vdr: emit upstart-signal stopped for all plugins Jun 14 15:41:33 VDR vdr: [2613] dbus2vdr: upstart-signal stopped queued Jun 14 15:41:33 VDR vdr: [2613] dbus2vdr: stop DBus-Upstart-Signal-Sender Jun 14 15:41:50 VDR vdr: [2672] changing pids of channel 210 from 501+501=2:502=deu@3:0:0 to 401+401=2:402=deu@3:0:0 Jun 14 15:42:32 VDR kernel: [ 900.436158] init: vdr main process (2613) killed by KILL signal
Beim Stop bleibt der Vdr allerdings hängen, der Thread läuft weiter mit fast 100% CPU und wird nach 60 Sekunden vom Watchdog unsanft beendet. Dazu könnte passen, dass der Thread keine Logmeldung mehr im syslog hinterlässt. Es sieht also so aus, als ob sich der Thread nicht mehr per stop DBUS-Upstart-Signal-Sender beenden lässt.
Klaus
-
irgendwie geht init bzw. upstart damit in die knie.
-
Hi,
Zitatirgendwie geht init bzw. upstart damit in die knie.
Ich nehme an du ziehst diese Info aus folgendem Eintrag:
CodeJun 14 15:30:30 VDR vdr: [2700] dbus2vdr: DBus-Upstart-Signal-Sender thread started (pid=2613, tid=2700)
Das es an Upstart liegen könnte wurde im Bugtracker ja auch schon angesprochen,
nur wie kommen wir dem auf die Schliche? -
ich hatte das mal wenn sich 2 "gleiche" jobs in die quere kommen.
will heissen vdr-frontend läuft schon aus etc/init , aber lässt sich als user nochmal starten
in /var/lib/vdr/.init/vdr.frontend.conf
und dann kracht es.evtl. ist es da ähnlich. der job wird mehrmals gestartet obwohl eigentlich nicht möglich, und dadurch knallt es.
aber das ist wieder mein stochern. wenn ich ehrlich bin, hab ich keine ahnung von dem kram.
und will es auch nie haben. viel zu anstrengend .... -
-
ich hatte das mal wenn sich 2 "gleiche" jobs in die quere kommen.
will heissen vdr-frontend läuft schon aus etc/init , aber lässt sich als user nochmal starten
in /var/lib/vdr/.init/vdr.frontend.conf
und dann kracht es.evtl. ist es da ähnlich. der job wird mehrmals gestartet obwohl eigentlich nicht möglich, und dadurch knallt es.
aber das ist wieder mein stochern. wenn ich ehrlich bin, hab ich keine ahnung von dem kram.
und will es auch nie haben. viel zu anstrengend ....
Nur warum tritt das Problem nur bei wenigen Usern auf? Muss ja dann doch irgendwie Hardware-bedingt sein.
In meiner VM habe ich weitaus weniger CPU-Last. -
Zitat
In meiner VM habe ich weitaus weniger CPU-Last.
Mein Headless System läuft auch in einer vm.
Ist ebenfalls von dem Problem betroffen...Munter bleiben, Rossi
-
na... irgendwelche gemeinsamkeiten müssen wir doch haben...
der einwand von ofenheizer ist schon berechtigt, warum haben es einige user und andere nicht? -
Hallo,
Ich habe gerade einen vielleicht interessanten Effekt gesehen: Wenn ich den dbus-daemon mitten im laufenden Betrieb kille (kill -9 ...) dann wird er automatisch gleich wieder gestartet, die CPU-Auslastung sinkt aber auf ca. 15 % (!!!!) bei meinem Sempron und der vdr läuft weiter.
Im Moment geht alles, die Auslastung bleibt niedrig.Mir war noch was aufgefallen: Als ich in der Prozessliste zum ersten Mal nach dem dbus-daemon gesucht habe, waren zwei unabhängige dbus-daemon-Prozesse mit unterschiedlichen Parametern zu sehen. Ich habe beide gekillt, worauf wieder einer automatisch neu gestartet wurde. Nach einem Ausschalten (nach S3 !) und wieder hochfahren war nur noch ein dbus-daemon zu sehen, aber die Auslastung wieder bei 100 %. Daemon gekillt und die Auslastung war wieder bei 15 %, der daemon ist gleich wieder neu gestartet. Seit dem läuft der VDR, alles geht.
Bleiben also zwei Fragen:
- Werden bei einem kompletten Reboot zwei Dbus-daemon-Prozesse erzeugt ? Kann ich erst später testen, jetzt muss der Fernseheer erst mal laufen (Alpha-Version im Wohnzimmer !).
- Wird der jetzt laufende daemon zu früh erzeugt ?Ich bleib dran.
Klaus
-
kann ich bestätigen. Ich hab einen der beiden dbus-daemons (487) gekilled und schon ging der Load runter!
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!