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

    danke fürs "stochern", aber hier ist kein softhddevice im einsatz.
    dbus2vdr trotzdem mal weiter nach vorne nehmen? an dem betreffenden vdr (nur per fernwartung erreichbar) ist xineliboutput im einsatz.

    Zitat von BooStar

    @mboka und ofenheizer
    vllt sollen wir mal unsere Hardware vergleichen,
    bei mir kommt es auf dem erstem system in meiner signatur vor da, ist auch sonst nichts drin, außer noch einem yausbir


    naja, hatte ich ja in meinem post geschrieben ... mainboard ist das gleiche Asus M2NPV-VM. der rest ist unterschiedlich ... Sempron LE-1250, G210, TT-1600, 1 DigitalDevice Dual-Karte, 1GB Ram

    Zitat von hotzenplotz5

    naja ... dann halt xineliboutput


    ok, werde ich dann heute abend oder morgen früh testen ... ich denke mal während des fusi wird mein vater mich da nix machen lassen :D

    moin..
    also habs grad mal versucht...
    erste ohne dbus = cpu normal (kann auch zufall sein)(wird noch genauer getestet)
    dann mit dbus vor softhddevice = cpu hoch
    wobei mir grade folgendes aufgefallen ist:

    Code
    Jun 11 18:06:49 yavdr vdr: [1983] ERROR: dbus2vdr message handler thread 1983 won't end (waited 3 seconds) - canceling it...


    kann das ein grund sein?


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

    so.. das war der vierte reboot ohne dbus..
    cpu normal... es kommt zwar kein bild, aber die cpu verhaelt sich normal...
    maql gucken was passiert, wenn ichs jetzt an die erste stelle der order.conf setzte...


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

    so.. order.conf sieht so aus:

    Code
    dbus2vdr
boese
softhddevice
*dynamite


    cpu bei 95%


    //edit: wenn ich jetzt ein restart vdr mache, ist die cpu normal
    //edit2: wenn ich noch ein restart vdr mache, ist die cpu wieder auf 95%


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

    2 Mal editiert, zuletzt von BooStar ()

    Ich hab jetzt bei mir auch mal alle Plugins raus geschmissen, ohne DBUS kommt kein Bild und der CPUuse ist auf 1.3 runter. Aber da macht er ja auch garnichts. Ich denke nicht das es mittelbar mit dem dbus2vdr zu tun hat, sondern wenn man das raus schmeisst macht der VDR ja nicht mehr viel was Last verursachen könnte.


    Die Reihenfolge ändert leider nichts. Die einzigen Plugins die ich jetzt noch laufen habe sind:


    Code
    Jun 11 19:25:31 rose vdr: [1069] initializing plugin: dbus2vdr (0.0.7a): control vdr via D-Bus
Jun 11 19:25:31 rose vdr: [1069] initializing plugin: streamdev-client (0.6.0-git): VTP Streaming Client
Jun 11 19:25:31 rose vdr: [1069] initializing plugin: softhddevice (0.5.1): A software and GPU emulated HD device


    Jetzt nehm ich statt softhddevice noch xine und xinelibout und schau mal was da passiert.

    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

    hallo

    das kann ich mal so bestätigen habe eben eine frische Installation hochgezogen, genau das selbe verhalten.
    das bei nicht geladenem dbus2vdr-plugin kein bild kommt, liegt daran das, dass softhddevice nicht attached ist, das kann man händisch ändern..

    Zitat

    Jetzt nehm ich statt softhddevice noch xine und xinelibout und schau mal was da passiert.

    ich würde tippen, das die cpu-last hoch ist, aber ein bild kommt...
    @mboka:
    welche hardware setzt du ein? //edit: scheint die aus der signatur zu sein ..
    @hoplo:
    haste noch mehr ideen, wo man ansetzen könnte?


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

    Hab jetzt alle xinelibout, xine, softhddevice und headless probiert. Bei allen das gleiche 99% CPUuse.


    Einzig dbus2vdr deaktivieren bringt besserung, aber dann ist der VDR nicht benutzbar.


    Mein Mainboard:


    Code
    Base Board Information
    	Manufacturer: Gigabyte Technology Co., Ltd.
    	Product Name: P35-S3G


    Mein Syslog auch mal (wieder mit mehr Plugins)


    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

    hab mich mal mit strace -p an den vdr gehängt, aber da werd ich auch nicht so schlau draus:


    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

    dito habe auch 97% CPU Last. Hardware siehe unten.

    Moin!


    Hm, ist ja interessant.
    Es kann aber auch sein, dass ein Programm, das dbus2vdr benutzt, die hohe Last verursacht.
    dbus2vdr ist relativ kommunikativ im Log, evtl. einfach mal den Loglevel des vdr zum Testen hochdrehen und alles mit "dbus2vdr" aus dem Syslog ansehen.


    Lars.

    Hallo,


    ich habe vor ein paar Tagen die 0.5alpha1 installiert und habe auch den Effekt mit einer dauerhaften 95-100%igen CPU-Auslastung. Ich habe mit htop in den vdr-threads festgestellt, dass nur ein Thread (hatte hier mal die TID 5266) die hohe Auslastung erzeugt. Im syslog ist die Thread-ID aber bei laufendem VDR nicht protokolliert.


    Wenn ich aber einen restart vdr absetze, dann finden sich nach dem Restart folgende Einträge im syslog:

    Code
    Jun 12 14:56:02 VDR vdr: [5266] dbus2vdr: emit upstart-signal vdr-plugin for started
Jun 12 14:56:02 VDR vdr: [5266] dbus2vdr: SendSignal: monitor has no connection, try to connect
Jun 12 14:56:02 VDR vdr: [5266] dbus2vdr: established connection for sending signals
Jun 12 14:56:02 VDR vdr: [5266] dbus2vdr: emit upstart-signal vdr-plugin for stopped
Jun 12 14:56:03 VDR vdr: [5266] dbus2vdr: DBus-Upstart-Signal-Sender thread ended (pid=5179, tid=5266)


    Hängt da womöglich der Thread und wartet darauf, dass er was senden kann ?

    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!


    Die Thread-Ids sind nicht vdr-Start-übergreifend eindeutig. Die Id 5266 kann vorher ein anderer Thread gehabt haben als nach einem vdr-Neustart.


    Wenn der Thread zum Versenden eines dbus-Signals keine Verbindung hat, dann versucht er, sich neu zum dbus-System-Bus zu verbinden.
    Die Verbindung scheint irgendwie unterbrochen worden zu sein. Das kann schon mal passieren und das Plugin rechnet damit.
    Es kann aber auch sein, dass es in testing eine ältere Version als in unstable gibt, keine Ahnung, wann ich da die letzten Unebenheiten (hoffentlich) behoben habe.
    Der Reconnect läuft aber auch innerhalb einer Sekunde durch, ich denke nicht, dass das das Problem ist.


    Was sagt denn das Log über den dbus-daemon? Wurde der zwischendurch mal neugestartet oder so?


    Lars.

    Hallo mini,


    Zitat

    Was sagt denn das Log über den dbus-daemon? Wurde der zwischendurch mal neugestartet oder so?

    Ich werde versuchen heute abend mal ein Log mit hohem Loglevel zu posten.


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

    Zitat von mini73

    Es kann aber auch sein, dass es in testing eine ältere Version als in unstable gibt, keine Ahnung, wann ich da die letzten Unebenheiten (hoffentlich) behoben habe.


    mein betreffendes system ist noch mit einer älteren iso installiert, als der alpha1. hier sind noch die unstable-repos eingebunden. seit installation und meinem bugtracker-eintrag alles auf unstable.


    an die logs komm ich grad nicht ran.

    Noch mal meine Logeinträge etwas genauer (mir hatte das rate-limit einen Streich gespielt):


    Wenn der VDR startet, kommen folgende plugin-bezogenen Meldungen im syslog:


    Darin ist sehen, dass unter TID 1721 der DBus-Upstart-Signal-Sender thread gestartet wird. Dieser Thread gibt dann keine Meldungen mehr aus, erzeugt aber (gesehen mit htop) die fast 100% CPU-Auslastung.


    Beim Beenden des VDR werden dann folgende Meledungen ausgegeben:


    Der Thread 1721 meldet sich beim Stoppen des Plugin zunächst mit "emit upstart-signal vdr-plugin for started" und später mit den 4 Meldungen am Ende.


    Mehr ist von diesem Thread nicht zu sehen, auch der DBus-Daemaon hinterlässt während der VDR-Laufzeit ansonsten keine Spuren im syslog.
    Mit mehreren VDR-Restarts ändert sich natürlich immer die TID, aber es ist immer der DBus-Upstart-Signal-Sender-Thread, der die CPU-Auslastung erzeugt.


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

    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 jetzt mal versucht mehr logging (-l 3) raus zu bekommen, aber mehr als der default level 3 kommt leider nicht.

    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

    Moin!


    Zitat von klausL

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


    Es ist zumindest ein Ansatzpunkt. Ich werde den Code da morgen mal einem intensiven Review unterziehen.


    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