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

startest du aus s3 ?

ja aus S3. Hab gerade im irserver-Thema gelesen, dass das "on resume" in der start on-Zeile wohl den Ärger verursacht.

Das ist seit heute Mittag wieder raus...

ist das weg (die hohe cpu last) wenn das "on resume" gelöscht wird ?

https://github.com/yavdr/yavdr…4224bbe9fc3ad6c1d6aa453cc

im paket hab ich das übrigens schon rausgenommen.

ja, nach Ruhezustand und Wiederhochfahren kommt kein irserver mehr.
Das scheint also erledigt zu sein.

Nach dem update und reboot kommt bei mir auch kein irserver mehr, aber Hohe CPU-Last 97% habe ich trotzdem noch.

top - 00:48:15 up 8 min,  2 users,  load average: 4.33, 3.24, 1.68
Tasks: 119 total,   2 running, 117 sleeping,   0 stopped,   0 zombie
Cpu(s): 96.4%us,  2.0%sy,  0.3%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.3%si,  0.0%st
Mem:   3533156k total,   622724k used,  2910432k free,    20704k buffers
Swap:   265068k total,        0k used,   265068k free,   197312k cached


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1027 vdr       10 -10 1407m 152m  20m S 97.4  4.4   7:03.83 vdr
 1756 root      20   0     0    0    0 S  1.0  0.0   0:04.37 cx88[0] dvb
 1143 root      20   0  739m 9920 5872 S  0.3  0.3   0:01.86 tntnet
 1410 root      20   0     0    0    0 S  0.3  0.0   0:01.68 kdvb-ad-1-fe-0
    1 root      20   0 24820 2732 1348 S  0.0  0.1   0:01.04 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
    7 root      RT   0     0    0    0 S  0.0  0.0   0:05.03 watchdog/0
    8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset
    9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper
   10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs
   11 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 netns
   12 root      20   0     0    0    0 S  0.0  0.0   0:00.00 sync_supers
   13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 bdi-default
   14 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kintegrityd
   15 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kblockd
   16 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 ata_sff
   17 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khubd
   18 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 md
   19 root      20   0     0    0    0 S  0.0  0.0   0:00.03 kworker/0:1
   21 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khungtaskd
   22 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kswapd0
   23 root      25   5     0    0    0 S  0.0  0.0   0:00.00 ksmd
   24 root      39  19     0    0    0 S  0.0  0.0   0:00.00 khugepaged
   25 root      20   0     0    0    0 S  0.0  0.0   0:00.00 fsnotify_mark
   26 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ecryptfs-kthrea
   27 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 crypto
   35 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kthrotld
   38 root      20   0     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_0
   39 root      20   0     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_1

Bei mir ists seit dem heutigen Update auch behoben! Vielen Dank!

Sicherheitshalber zur Klarstellung:
Bei mir ist nach wie vor ein VDR-Thread wie weiter oben beschrieben mit nahezu 100 % CPU-Last zu sehen. Erst nach restart dbus geht die Last runter.
An diesem Thema müssten wir also noch dran bleiben.

klausL

Hi,

habe hier das selbe Problem mit 99% CPU last mit der HW in der Sig.
sudo restart dbus - schafft Abhilfe, kann ich bestätigen.

aktuell behoben, indem ich das dbus Plugin deaktiviert habe (bei headless brauch ich das nicht - oder?)

Hier meine order.conf

##firstplugin
##secondplugin
##*lastplugin
##-thirdplugin
##-fourthplugin
##*anotherlastplugin


-dbus2vdr


*dynamite
-dvbhddevice
-dvbsddevice
-pvr350
dummydevice
-xine
-xineliboutput
-graphtft
-softhddevice
-lcdproc
-imonlcd
-text2skin
-menuorg
-yaepghd
-extrecmenu
-suspendoutput

Ich versuche mich an yaVDR als reinen Streaming-Client für den headless Server. Der Client-VDR hat nach einem Neustart nahezu 100% CPU Last.
Interessant finde ich allerdings dann folgendes:
Wenn die Last bei 100% liegt, wird das syslog mit Meldungen der Art

Jun 18 21:50:24 vdr1 vdr: [2729] cStreamdevFilter::PutSection socket overflow, Pid 18 Tid 64
Jun 18 21:50:24 vdr: last message repeated 199 times
Jun 18 21:50:24 vdr1 rsyslogd-2177: imuxsock begins to drop messages from pid 2370 due to rate-limiting
Jun 18 21:50:30 vdr1 rsyslogd-2177: imuxsock lost 2136 messages from pid 2370 due to rate-limiting
Jun 18 21:50:30 vdr1 vdr: [2729] cStreamdevFilter::PutSection socket overflow, Pid 18 Tid 64
Jun 18 21:50:30 vdr: last message repeated 199 times
Jun 18 21:50:30 vdr1 rsyslogd-2177: imuxsock begins to drop messages from pid 2370 due to rate-limiting
Jun 18 21:50:36 vdr1 rsyslogd-2177: imuxsock lost 2424 messages from pid 2370 due to rate-limiting
Jun 18 21:50:36 vdr1 vdr: [2729] cStreamdevFilter::PutSection socket overflow, Pid 18 Tid 64
Jun 18 21:50:36 vdr: last message repeated 199 times

geflutet, bis zu dem Punkt, an dem das Bild einfach stehen bleibt.

Nach einem restart dbus, dreht sich das Verhalten um 180 Grad. Die CPU Last sinkt extrem und das syslog bleibt frei von unerwünschten Meldungen. BIsher trat auch kein Freeze des Bildes mehr auf.
2370 ist der VDR selber.

Zabrimus

Die Fehlermeldungen sind Folge-Fehler und in sofern nichts ungewöhnliches. Ehrlich gesagt wäre es uns lieber wenn mehr Nicht-Headless-User das ISO testen würden, da der Headless-Betrieb nicht die Standard-Betriebsart von yaVDR ist.

Gerald

Habe auch das Problem mit der hohen CPU Last bei meinem HTPC2-System. Ist ein normales Yavdr-System All-in-one-Box.

Ein

sudo restart dbus

bringt die Last runter auf wenige Prozent.

In 11.04'er Ubuntu Version gab es das Problem scheinbar schonmal. Da half bei einem User:
https://bugs.launchpad.net/ubu…ource/kdelibs/+bug/779849

Zitat:

I added the following 2 lines to /etc/security/limits.conf file, and I have not experienced the 100% CPU saturation issue with dbus_daemon for 17 days:
* soft nofile 65536
* hard nofile 65536

Werde das mal ausprobieren heute Abend.

Hier der Bugreport für Ubuntu 12.04
https://bugs.launchpad.net/ubuntu/+source/bamf/+bug/964811

Joe

Zitat von DocViper

Werde das mal ausprobieren heute Abend.

Wäre schön, wenn du vorab mit strace verifizieren könntest, dass es um die gleiche Ursache geht. In dem Thread geht es um einen Fehler in einer KDE-Lib, die haben wir zwar nicht, aber möglicherweise machen wir den gleichen Fehler.

Gerald

Moin!

Die DBus-Doku ist da etwas schwammig, was man wie zu tun hat, wenn man eine Verbindung zum Systembus aufnehmen möchte.
Und so richtig deutlich wird es auch nicht, was man tun soll, wenn man die Verbindung beendet.
Und es scheint ja auch nicht bei jedem aufzutreten.

Was passiert, wenn ihr den vdr stoppt, dbus neustartet und dann den vdr wieder startet?
Wenn dann alles in Ordnung ist, würde ich es eher auf einen Konflikt beim schnellen Booten schieben.
Eventuell wäre es dann am sinnvollsten, bei den Upstart-Jobs anzusetzen.

• Ich denke, die dbus-activiation sollte wieder raus.
• Wir müssen dafür sorgen, dass alle vdr-dbus-send-Aufrufe erst nach dem Start des vdr passieren.
• Der Start des vdr sollte vom dbus-Daemon abhängig sein.

Teilweise sind diese Dinge schon so umgesetzt, aber es scheint nicht immer so zu funktionieren.

Kann man Upstart noch irgendwie dazu bringen, genauer zu protokollieren?
Und am besten einen "logger"-Aufruf in vdr-dbus-send einbauen, damit wir sehen, wann es mit welchen Parametern aufgerufen wird.

Lars.

Zitat von mini73

Was passiert, wenn ihr den vdr stoppt, dbus neustartet und dann den vdr wieder startet?

bei einem vdr-neustart ist die last wieder hoch. ein erneutes restart dbus senkt sie wieder auf normal.

Sollte eigentlich mit

sudo strace -p xxx

wobei xxx die Prozess ID ist.

PID über HTOP oder ps ermitteln.

Vermutlich kann man auch mit dem Tool "dbus-monitor" noch Erkenntnisse gewinnen.