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

    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

    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!


    Zitat von klausL

    Würd' mich freuen, wenn das zur "Erhellung" beiträgt.


    Siehst du danach noch sowas wie:

    Code
    dbus2vdr: can't emit upstart-signal


    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

    yavdr 0.5, Mainboard: Asus M4N78-VM, 4 Gbyte RAM, CPU Sempron 140, DVB-S2: IPTV von GSS DSI.400, Display: Futaba MDM166A, Fernbedienung: Activiy-FB silber, Receiver Denon AVR-1910, TV Samsung UE40B6000
    DSI.400 Sat-IP-Server

    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,


    Zitat

    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.

    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...


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    Zitat von mini73

    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!


    Zitat von BooStar

    aber leider komme ich wohl erst am Wochenende dazu...


    Keine Eile...

    Zitat von ofenheizer

    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...


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    Moin!


    Zitat von BooStar

    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):



    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):



    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

    yavdr 0.5, Mainboard: Asus M4N78-VM, 4 Gbyte RAM, CPU Sempron 140, DVB-S2: IPTV von GSS DSI.400, Display: Futaba MDM166A, Fernbedienung: Activiy-FB silber, Receiver Denon AVR-1910, TV Samsung UE40B6000
    DSI.400 Sat-IP-Server

    Hi,

    Zitat

    irgendwie geht init bzw. upstart damit in die knie.

    Ich nehme an du ziehst diese Info aus folgendem Eintrag:

    Code
    Jun 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?


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    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 ....

    was ist das denn für ein job?

    Code
    DBus-Upstart-Signal-Sender


    ??


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy


    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?


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

    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

    yavdr 0.5, Mainboard: Asus M4N78-VM, 4 Gbyte RAM, CPU Sempron 140, DVB-S2: IPTV von GSS DSI.400, Display: Futaba MDM166A, Fernbedienung: Activiy-FB silber, Receiver Denon AVR-1910, TV Samsung UE40B6000
    DSI.400 Sat-IP-Server

    kann ich bestätigen. Ich hab einen der beiden dbus-daemons (487) gekilled und schon ging der Load runter!


    Code
    102    	487  0.0  0.0  24188  1552 ?    	Ss   20:13   0:00 dbus-daemon --system --fork --activation=upstart
root   	950  0.0  0.0  23808   436 ?    	Ss   20:13   0:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session

    Wohnzimmer VDR: Silverstone LC20, Celeron 430, 2 GB Ram, 16GB SSD, 8' TFT TM-868, 4,5TB per CIFS gemountet, yavdr 0.4/0.5, Harmony One, GT220, Speedlink 7.1 (CMI8768 ), Streamingclient, 46XV733


    Keller-Stream/Storage-VDR: Core2Duo, 4GB Ram, 3x TT-S2-1600, 1 x Satelco DVB-S Basic, yavdr 0.5, 6TB Storage

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden