Verzögerung bei der Ausführung von Rules

[chru]

Hallo,

ich habe eine starke Verzögerung beim ausführen der Rules. Ich verwende openhab 1.5 auf einem Raspberry Pi mit Raspbian und Java 1.8. Das Logfile zeigt mir beim ausführen dieser Rule

rule "Start/Stop TV-Beleuchtung"
when
    Item Zentral_Szene_TV received command
then
    var szene_tv_aktiv = receivedCommand
    
    if(szene_tv_aktiv == ON)
    {
        Licht_EG_Wohnzimmer_Decke.sendCommand(ON)
        
        Dimmer_EG_Wohnzimmer_Rot.sendCommand(20)
        Dimmer_EG_Wohnzimmer_Gruen.sendCommand(20)
        Dimmer_EG_Wohnzimmer_Blau.sendCommand(90)
    }
    else
    {
        Dimmer_EG_Wohnzimmer_Rot.sendCommand(0)
        Dimmer_EG_Wohnzimmer_Gruen.sendCommand(0)
        Dimmer_EG_Wohnzimmer_Blau.sendCommand(0)
        
        Licht_EG_Wohnzimmer_Decke.sendCommand(OFF)
    }
end

folgendes an:

2014-07-27 11:56:06 - Zentral_Szene_TV received command ON
2014-07-27 11:56:06 - Licht_EG_Wohnzimmer_Decke received command ON
2014-07-27 11:56:16 - Dimmer_EG_Wohnzimmer_Rot received command 20
2014-07-27 11:56:19 - Dimmer_EG_Wohnzimmer_Gruen received command 20
2014-07-27 11:56:21 - Dimmer_EG_Wohnzimmer_Blau received command 90

Auch wenn der Raspberry sicherlich nicht die Leistungsstärkste HW ist, denke ich, dass es in weniger als 15s möglich sein sollte, diese Rule auszuführen. Arbeitsspeicher und Prozessorleistung sind auch noch vorhanden:

             total       used       free     shared    buffers     cached
Mem:        496764     317464     179300          0      17068     128316
-/+ buffers/cache:     172080     324684
Swap:       102396          0     102396


             total       used       free     shared    buffers     cached
Mem:        496764     317464     179300          0      17068     128316
-/+ buffers/cache:     172080     324684
Swap:       102396          0     102396

%CPU   PID USER     COMMAND
23.4  2031 root     /usr/bin/java -Dosgi.clean=true -Declipse.ignoreApp=true -Do
sgi.noShutdown=true -Dgnu.io.rxtx.SerialPorts=/dev/usb-serial -Djetty.port=8080
-Djetty.port.ssl=8443 -Djetty.home=/opt/openhab/openhab-runtime -Dlogback.config
urationFile=/opt/openhab/openhab-runtime/configurations/logback.xml -Dfelix.file
install.dir=/opt/openhab/openhab-runtime/addons -Djava.library.path=/opt/openhab
/openhab-runtime/lib -Djava.security.auth.login.config=/opt/openhab/openhab-runt
ime/etc/login.conf -Dorg.quartz.properties=/opt/openhab/openhab-runtime/etc/quar
tz.properties -Djava.awt.headless=true -jar /opt/openhab/openhab-runtime/server/
plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar -console 5555
 0.0     9 root     [rcu_sched]
 0.0  9488 pi       -bash
...

Hat jemand eine Idee, woran es liegen könnte?

[thoern]

Hi,

bei der Prozessorleistung wäre eher die Load (uptime, top) oder noch besser die Ausgabe von
vmstat 2
interessant. Natürlich über den kompletten Zeitraum der Rule-Ausführung.

Gruß,
thoern

[chru]

Geht es nach vmstat und wenn ich die Ausgabe richtig deute, ist die CPU auch beim nicht ausführen der Rule sehr oft bei 100%. Hier ein Ausschnitt:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 4  0      0 175364  17204 129600    0    0     0     0 5424 2483 89 11  0  0
 3  0      0 175300  17204 129600    0    0     0     0 5421 2517 79 21  0  0
 3  0      0 175300  17204 129600    0    0     0     0 5450 2521 80 20  0  0
 3  0      0 175300  17204 129600    0    0     0     0 5412 2512 90 10  0  0
 3  0      0 175300  17204 129600    0    0     0     0 5429 2514 78 22  0  0
 4  0      0 175340  17204 129600    0    0     0     0 5427 2526 73 27  0  0
 3  0      0 175332  17204 129600    0    0     0     0 5365 2454 87 13  0  0
 2  0      0 175332  17204 129604    0    0     0     0 5382 2468 74 26  0  0
 3  0      0 175332  17204 129604    0    0     0     0 5428 2506 83 17  0  0

[thoern]

Geht es nach vmstat und wenn ich die Ausgabe richtig deute, ist die CPU auch beim nicht ausführen der Rule sehr oft bei 100%.

Ja, genau. Man sieht sehr schön, dass die Idle-Time ständig 0 ist (= 100%-ige CPU-Auslastung). In der ersten Spalte "r" werden die Prozesse in der Run-Queue angezeigt. Bei einem performanten System ist dieser Wert überwiegend 0 und geht selten auf/über 1.
Wenn die Werte ständig so hoch sind, ist das System CPU-technisch überlastet. Entweder du stoppst alles was sonst nicht zwingend notwendig ist, oder besser noch, du besorgst dir eine ordentliche Hardware

Gruß,
thoern

[PascalTurbo]

Hi,

ich hab komplexere Regeln auf nem Raspi laufen - ohne Probleme.

Schau doch mal, was genau die Performance verbrät (TOP). Vll. läuft irgend ein Prozess, der nicht laufen soll.

VG

[chru]

Wenn ich top verwende bekomme ich folgende Ausgabe:

top - 12:48:17 up  7:47,  1 user,  load average: 0,70, 0,84, 0,83
Tasks:  62 total,   1 running,  61 sleeping,   0 stopped,   0 zombie
%Cpu(s): 79,0 us, 13,1 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  7,9 si,  0,0 st
KiB Mem:    496764 total,   281760 used,   215004 free,    12844 buffers
KiB Swap:   102396 total,        0 used,   102396 free,   127180 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 2050 root      20   0  259m 125m  10m S  98,9 25,8 103:39.27 java
10256 pi        20   0  5220 1356 1028 R   1,0  0,3   0:02.37 top
 2018 ntp       20   0  5384 1600 1252 S   0,3  0,3   0:05.63 ntpd
 7279 root      20   0     0    0    0 S   0,3  0,0   0:02.33 kworker/0:1
    1 root      20   0  2148  720  616 S   0,0  0,1   0:02.74 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:09.40 ksoftirqd/0
    5 root       0 -20     0    0    0 S   0,0  0,0   0:00.00 kworker/0:0H
    6 root      20   0     0    0    0 S   0,0  0,0   0:00.10 kworker/u2:0
    7 root      20   0     0    0    0 S   0,0  0,0   0:05.66 rcu_preempt
    8 root      20   0     0    0    0 S   0,0  0,0   0:00.00 rcu_bh
    9 root      20   0     0    0    0 S   0,0  0,0   0:00.00 rcu_sched
   10 root       0 -20     0    0    0 S   0,0  0,0   0:00.00 khelper
   11 root      20   0     0    0    0 S   0,0  0,0   0:00.00 kdevtmpfs
   12 root       0 -20     0    0    0 S   0,0  0,0   0:00.00 netns
   13 root       0 -20     0    0    0 S   0,0  0,0   0:00.00 writeback
   14 root       0 -20     0    0    0 S   0,0  0,0   0:00.00 bioset

Allerdings ist java hierbei nicht immer auf einen so hohen Wert.
Die Bindings die ich verwende sind folgende:
org.openhab.action.squeezebox-1.5.0.jar
org.openhab.action.xmpp-1.5.0.jar
org.openhab.binding.comfoair-1.5.0.jar
org.openhab.binding.exec-1.5.0.jar
org.openhab.binding.fritzbox-1.5.0.jar
org.openhab.binding.http-1.5.0.jar
org.openhab.binding.knx-1.5.0.jar
org.openhab.binding.mqtt-1.5.0.jar
org.openhab.binding.ntp-1.5.0.jar
org.openhab.binding.serial-1.5.0.jar
org.openhab.binding.squeezebox-1.5.0.jar
org.openhab.io.squeezeserver-1.5.0.jar

Die ganzen Persistence Geschichten habe ich schon rausgeschmissen...

[PascalTurbo]

Wenn ich top verwende bekomme ich folgende Ausgabe:

Die Bindings die ich verwende sind folgende:
org.openhab.action.squeezebox-1.5.0.jar
org.openhab.action.xmpp-1.5.0.jar
org.openhab.binding.comfoair-1.5.0.jar
org.openhab.binding.exec-1.5.0.jar
org.openhab.binding.fritzbox-1.5.0.jar
org.openhab.binding.http-1.5.0.jar
org.openhab.binding.knx-1.5.0.jar
org.openhab.binding.mqtt-1.5.0.jar
org.openhab.binding.ntp-1.5.0.jar
org.openhab.binding.serial-1.5.0.jar
org.openhab.binding.squeezebox-1.5.0.jar
org.openhab.io.squeezeserver-1.5.0.jar

Die ganzen Persistence Geschichten habe ich schon rausgeschmissen...

OK, das sind denke ich zu viele Bindings für den Raspberry Pi. Jedes für sich braucht ziemlich sicher nicht zu viele Ressourcen, aber die Kombination dürfte zu viel des guten sein.
Da muss wohl doch schnellere Hardware her. (oder weniger Bindings)

[chru]

Ich bin mir nicht ganz sicher, ob es an der Anzahl der Bindings liegt. Ich habe nur noch das KNX-Binding in den addons-Ordner und die CPU-Auslastung geht an die 100% beim ausführen der Rule. Im Leerlauf sieht es allerdings zum Teil etwas besser aus. Kann die Anzahl der Items oder die Anzahl der Rules noch eine Rolle spielen?

[thoern]

Hi,

tue dir selbst einen Gefallen und besorg dir eine leistungsfähigere HW. Vielleicht könntest du das Eine oder Andere sogar optimieren, aber ob du auf Dauer damit glücklich wirst, wenn Installation und Anforderungen wachsen...

Gruß,
thoern

[chru]

Vielleicht noch eine Frage: Nehmen Groups auch Systemresourcen während des Betriebs in Anspruch?