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

    mich würde das interessieren :


    iso erneut installieren. keine zusätzlichen plugins installieren.
    keine skins zus. nur apt-get update und upgrade.


    und wie es dann aussieht.
    seh ich mir manche logs an versteh ich mehr nicht als nur die cpu last.


    z.b. :


    Code
    Jun 11 19:41:35 rose vdr: [5776] streamdev server thread started (pid=5718, tid=5776)
Jun 11 19:41:35 rose vdr: [5776] ERROR: no streamdev server activated, exiting
Jun 11 19:41:35 rose vdr: [5776] streamdev server thread ended (pid=5718, tid=5776)


    Code
    Jun 11 19:41:35 rose vdr: [5718] skin "anthra_1920_FSE" not available - using "sttng" instead


    Code
    Jun 11 19:41:35 rose vdr: [5718] ERROR: unknown config parameter: streamdev-client.SyncEPG = 0
Jun 11 19:41:35 rose vdr: [5718] ERROR: unknown config parameter: streamdev-server.SuspendMode = 1


    usw. usw.
    haben wir das so standardmässig ?

    Ich habe mal etwas weiter geforscht und noch ein paar Effekte gefunden:
    - Nach dem "restart dbus" geht ja die CPU-Last runter. Wenn man dann einen "restart vdr" absetzt, ist die Auslastung wieder bei 100 %.


    - Ich habe auf der dbus-Seite das Monitoring angeworfen, um zu sehen, was da ankommt.


    Beim Starten des VDR an der Konsole ("start vdr") sieht der dbus-monitor etwa 60 Ereignisse, die schnell hintereinander ablaufen:



    Nach der letzten Meldung ist dann Ruhe. Wie gehabt ist dann die CPU-Last bei 100%, erzeugt durch einen der VDR-Threads.


    Ein strace mit der Thread-ID desjenigen Thread, der die CPU auslastet (also noch vor dem restart dbus), bleibt schlichtweg leer !
    Nach einem restart dbus wird aber direkt etwas protokolliert:


    Ab gettid()... erscheint direkt nach dem restart dbus.


    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 das hier ein Hinweis sein ?


    Code
    sendto(3, "<11>Jun 19 15:15:28 vdr: [14239]"..., 85, MSG_NOSIGNAL, NULL, 0) = 85


    Ist dass der Trigger für das NoSignal Logo ?

    Moin!


    "sendto" ist das Schreiben in einen Socket, das sieht nach einer Meldung ins Syslog aus, "MSG_NOSIGNAL" hat nichts mit dem "no signal"-Logo zu tun.


    Da versucht jemand, eine Verbindung aufzubauen, was aber nicht klappt (timed out), und das wird immer wieder probiert. Deshalb die Auslastung.
    Könnte das dbus2vdr-Plugin sein.
    Kann man noch Timestamps beim strace ausgeben lassen?


    Lars.

    Hallo,

    Zitat

    Kann man noch Timestamps beim strace ausgeben lassen?


    Ja, das sollte mit

    Code
    strace -r

    gehen ...


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

    Das haben überflüssige Einträge in der setup.conf verursacht, ich hatte die einfach rein kopiert von der Version 0.4. Sind inzwischen raus.


    Den Streamdev-Server habe ich deaktiviert weil ich ihn nicht brauchte (der VDR holt sich alles von einem headless 0.4 per streamdev-client).


    Ich habe einmal alle Plugins ausser dem dbus-plugin deaktiviert, da blieb das Problem trotzdem erhalten.


    Weiter oben hatte ich geschrieben das es bei mir jetzt geht, leider nicht immer habe ich im Laufe des Tages festgestellt. Am WE werd ich nochmal weiter probieren. In der Woche habe ich leider keine Zeit :(

    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

    ja, auch Timestamps gehen. Hier noch mal der strace ab restart dbus:



    Ich habe gesehen, dass vor dem restart dbus der kritische Thread zwar keine Meldungen im strace produziert, aber unter der VDR-Prozess-ID werden auch solche Meldungen gezeigt. Hier ein kleiner Ausschnitt vom strace des VDR-Hauptprozesses vor dem restart dbus.



    Das könnte man womöglich auch so interpretieren, dass die Timeouts eigentlich immer da sind, und irgendwie die Übergabe in den Thread zu einem Hänger führt.


    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

    Hab ich auch grad gemacht. Hab auch die Meldungen wie KlausL


    Nach einem sudo restart vdr
    ist die CPU wieder am Kochen

    Zitat von mboka

    Den Streamdev-Server habe ich deaktiviert weil ich ihn nicht brauchte (der VDR holt sich alles von einem headless 0.4 per streamdev-client).


    Doch, du brauchst das. Die yaVDR-0.5-alpha1 ist für Tester. Änderungen an der Default-Konfiguration können die Testergebnisse verfälschen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Hallo..

    Zitat

    mich würde das interessieren :


    iso erneut installieren. keine zusätzlichen plugins installieren.
    keine skins zus. nur apt-get update und upgrade.


    und wie es dann aussieht.


    ich habe grade nochmal frisch installiert
    und dann das update gemacht.
    keine besserung, die der vdr hat immernoch 95%.
    die logs habe ich mal angehängt, vielleicht hilft das ja irgendwie..


    strace
    syslog_fresh
    syslog_updated


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

    Mal eine Anmerkung:


    man kann gdb an laufende Programme anklemmen.


    Code
    gdb /usr/bin/vdr `pidof vdr`


    mit "info threads" kann man sich die Threads auflisten lassen.
    mit "thread <nummer>" auf den Thread mit der hohen CPU Last umschalten.
    und dann mit bt gucken wo er denn so hängt.


    Vielleicht hilft das ja zur Fehlerursachesuche.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    moin johns,

    Zitat

    mit "thread <nummer>" auf den Thread mit der hohen CPU Last umschalten.


    wie bekomme ich den thread mit der hohen cpu raus?


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

    ok habs selber herausgefunden
    mit top die pid vom vdr suchen,
    dann ein ps -p 1357 -Lf
    dann ein

    Code
    gdb /usr/bin/vdr `pidof vdr`


    und das kommt raus:

    Code
    4    Thread 0x7ff7657fa700 (LWP 1650) "dbus2vdr: DBus-" 0x00007ff79842ddda in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
  3    Thread 0x7ff75ffff700 (LWP 1800) "Text2Skin: mess" 0x00007ff7a459d03d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
  2    Thread 0x7ff765ffb700 (LWP 1847) "dbus2vdr messag" 0x00007ff7a45c5b03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
* 1    Thread 0x7ff7a63f3740 (LWP 1357) "vdr" 0x00007ff7a5db10fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) thread 1650
Thread ID 1650 not known.
(gdb) thread 4
[Switching to thread 4 (Thread 0x7ff7657fa700 (LWP 1650))]
#0  0x00007ff79842ddda in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
(gdb)


    aber anfangen kann ICH damit leider nichts...:(
    //edit:
    das hat wohl gefehlt ;)


    anfangen kann ich damit trotzdem nichts ...;)


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

    2 Mal editiert, zuletzt von BooStar ()

    Zitat von BooStar

    anfangen kann ich damit trotzdem nichts ...;)


    Andere schon. Es ist die Bestätigung, dass hier wohl eine Loop ist, die ständig versucht DBUS-Signale loszuwerden. Da muss der mini73 wohl nochmal ran.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    moin..

    Zitat

    Andere schon.


    Das freut mich..

    Zitat

    Da muss der mini73 wohl nochmal ran.


    Das weniger ;) aber wenigstens ist das rumstochern vorbei ;)


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

    Zitat von BooStar

    Das weniger ;) aber wenigstens ist das rumstochern vorbei ;)


    Na ja, das wohl nicht. Warum es bei einigen zu dieser Loop kommt und bei anderen nicht, ist nach wie vor unklar.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Moin!


    Habe gerade die Funktion "dbus_threads_init_default" gefunden, die dafür sorgt, dass eine DBusConnection von mehreren Threads benutzt werden kann.
    Mal sehen, ob das hilft.


    Lars.

    Zitat

    Na ja, das wohl nicht. Warum es bei einigen zu dieser Loop kommt und bei anderen nicht, ist nach wie vor unklar.


    da hast du wohl recht..

    Zitat

    Habe gerade die Funktion "dbus_threads_init_default" gefunden, die dafür sorgt, dass eine DBusConnection von mehreren Threads benutzt werden kann.
    Mal sehen, ob das hilft.

    sehr gut, sag bescheid wenn es was neues gibt ;)


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

    Moin!


    Zitat von BooStar

    sehr gut, sag bescheid wenn es was neues gibt ;)


    Paket in unstable (Version 0.0.7c) wird gerade gebaut, dauert aber noch ein paar Minuten...


    Lars.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden