Hilfe: openHAB frisst im Minuten-Ryhthmus CPU

[staehler]

Hallo,

ich habe openHAB seit wenigen Tagen entdeckt und auf meinem QNAP Nas laufen.
Mittlerweile habe ich ein paar KNX-Geräte, 4 onewire Termometer, Wetterstation (HTTP-Binding), Wettervorhersage (HTTP-Binding), Squeezebox und Fritzbox angebunden und ein paar Rules erstellt. rrd4j läuft als Persistence Service.
Dies ist aber nur ein kleiner Teil dessen, was noch kommen soll. Da wir gerade im Bau sind, rede ich gerade von einer Testinstallation. Tatsächlich werden sich die KNX Geräte in etwa verdreifachen und die onewire-Sensoren gefühlt verzehnfachen.
Nur hat mein NAS (QNAP SS-439 Pro, Intel Atom 1.6 GHz, 1GB RAM) bereits jetzt schon Schwierigkeiten, seinen Job zu tun, da im Minuten Rhythmus für etwa 30 Sekunden die CPU komplett vom Java Prozess verschlungen wird:

Mem: 998104K used, 31584K free, 0K shrd, 270716K buff, 214568K cached
Load average: 1.27, 1.03, 1.01    (State: S=sleeping R=running, W=waiting)

  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
32649 admin    S       107M     1 99.9 10.6 java

Was sind die Ressourcenfresser? Was könnte falsch konfiguriert sein?

Diese Bindings habe ich im Einsatz:

-rw-r--r--    1 openhab  openhab      11.0k Dec 25 03:10 org.openhab.action.squeezebox-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      62.2k Dec 25 03:13 org.openhab.binding.exec-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      15.0k Dec 25 03:14 org.openhab.binding.fritzbox-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      18.3k Dec 25 03:13 org.openhab.binding.http-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab     387.1k Dec 25 03:12 org.openhab.binding.knx-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab       9.8k Dec 25 03:13 org.openhab.binding.networkhealth-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab       9.9k Dec 25 03:14 org.openhab.binding.ntp-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      42.3k Dec 25 03:13 org.openhab.binding.onewire-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      16.0k Dec 25 03:22 org.openhab.binding.owserver-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      14.2k Dec 25 03:22 org.openhab.binding.squeezebox-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      74.3k Dec 25 03:16 org.openhab.binding.tcp-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab      18.7k Dec 25 03:10 org.openhab.io.squeezeserver-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab       6.0k Dec 25 03:32 org.openhab.persistence.exec-1.4.0-SNAPSHOT.jar
-rw-r--r--    1 openhab  openhab     603.5k Dec 25 03:32 org.openhab.persistence.rrd4j-1.4.0-SNAPSHOT.jar

Meine frühere MisterHouse Installation (allerdings ohne onewire) lief auch auf diesem NAS und hat unauffällig im Hintergrund geschnurrt. Nur leider gefällt mir openHAB viel besser ;-) und es wird aktiv weiterentwickelt. Ich finde openHAB einfach genial!

Daher wäre ich für jede Hilfe sehr dankbar, denn so kann es leider nicht bleiben. Welche Info/Konfiguration ist für eine Bewertung hilfreich?

Viele Grüße
Michael

[staehler]

Ich habe, den Übeltäter wahrscheinlich gefunden:
ich polle meine Wetterstation im Minutentakt und dann folgt ein Parsen der Antwort. Was dasran allerdings so CPU-fressend ist, verstehe ich nicht.
Folgende Einstellungen:

############################ HTTP Binding ##########################################
#
# timeout in milliseconds for the http requests (optional, defaults to 5000)
#http:timeout=

# the interval in milliseconds when to find new refresh candidates
# (optional, defaults to 1000)
#http:granularity=

# configuration of the first cache item
# Wetterstation
http:ipweCache.url="http://192.168.2.138/ipwe.cgi"
http:ipweCache.updateInterval=60000

ipwe.items

/
Number IPWETemp     "Aktuelle Temperatur [%.1f C]"      <temperature>   (gAussenTemperatur)   {knx="2/0/1", http="<[ipweCache:60000:REGEX(.*?Kombi.*?<td.*td>.*?<td.*td>.*?<td.*>\\s*?(-?\\d.*) .C.*)]" }
Number IPWEHumi     "Luftfeuchtigkeit [%s %%]"  <humidity>      (gIPWE)   { http="<[ipweCache:60000:REGEX(.*?Kombi.*?<td.*td>.*?<td.*td>.*?<td.*td>.*?<td.*>\\s*?(\\d.*) %.*)]" }
Number IPWEWind     "Windstaerke: [%.1f km/h]"  <wind>          (gIPWE)   { knx="2/0/3", http="<[ipweCache:60000:REGEX(.*?Kombi.*?<td.*td>.*?<td.*td>.*?<td.*td>.*?<td.*td>.*?<td.*>\\s*?(\\d.*) km.*)]" }

String IPWERain     "Regen (24h) [%s mm]"       <rain>          (gIPWE)   { knx="2/0/4", http="<[ipweCache:60000:REGEX(.*?Kombi.*?<td.*td>.*?<td.*td>.*?<td.*td>.*?<td.*td>.*?<td.*td>.*?<td.*>(.*) mm.*)]" }

Was davon braucht so viel CPU? Wie kann ich das optimieren?

Viele Grüße
Michael

[thoern]

Servus Stähler!

den
http:ipweCache.updateInterval=60000

kannst du schon mal auf
http:ipweCache.updateInterval=150000

setzen. Häufigeres Polling macht keinen Sinn, da der IPWE sowieso nur ca. alle 150 Sekunken Daten vom Wettersensor bekommt. Vielleicht entschärft das deine Situation schon ein wenig...

Gruß,
Thomas

[staehler]

Hi Thomas,

leider hat das nicht geholfen. Da die items im Minuten-Takt anspringen, hat sich an der Situation leider nix geändert. Die Load springt leider noch genauso oft an die 99,9% :-(

Du merkst an Deinem Rechner überhaupt nichts, oder? Ich versteh's nicht!

Gruß Staehler

[HolgerW]

Hast du die Einträge in der Itemdatei auch geändert:

... ipweCache:60000 ...

Vielleicht auch unterschiedliche Zeiten eintragen damit nicht alle gleichzeitig loslaufen.

Holger

[staehler]

Also das HTTP-Binding scheint bei mir irgendwie sehr CPU hungrig zu sein. Erklären kann ich das auch nicht. Ich habe mir in diesem Fall mit thoern's ipwe-Perl Modul beholfen, ein kleines Perlskript erstellt und lasse dieses als exec laufen. Jetzt ist wieder Frieden auf dem NAS :-)
Allerdings wirft mir openhab.log jetzt Warnings:

==> events.log <==
2013-12-28 22:43:16 - IPWETemp state updated to 1.3
2013-12-28 22:43:16 - IPWETemp received command 1.3
2013-12-28 22:43:16 - Frostalarm state updated to ON
2013-12-28 22:43:16 - Frostalarm received command ON

==> openhab.log <==
22:43:16.139 WARN  o.o.b.e.internal.ExecBinding[:233]- doesn't find matching binding provider [itemName=IPWETemp, command=1.3]

Da wird offenbar die empfangene Aussentemperatur von 1,3 Grad als Befehl/command interpretiert.
Kann mir das einer erklären? Im Sitemap sehe ich die Temepratur korrekt. Also ich weiß nicht, was mir dieses Warning sagen will.