owserver hat immer mit 100% Systemlast

Begonnen von sweetie-pie, 08 Januar 2014, 13:35:49

Vorheriges Thema - Nächstes Thema

sweetie-pie

Hallo,

ich habe einen owserver auf meinem System in Einsatz. der owserver verursacht dauerhaft 100% Last auf einem Kern.

Unter top sieht der Kern dann so aus:
Cpu1  : 29.9%us, 70.1%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
~ 1/3 Userspace 2/3 Kernelspace

Und so der Prozess:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                     
21843 root      20   0 35540 1200  904 R  100  0.1   1344:41 /opt/owfs/bin/owserver -c /etc/owfs.conf --pid-file /var/run/owserver.pid


Als Adapter habe ich so einen USB-1Wire-Adapter vom Chinesen USB9097R -=> http://pcsensor.com/index.php?_a=product&product_id=33

Am Bus hängen insgesamt 11x DS18B20 die von fhem wie folgt gepollt werden:

4 Stück alle 60 Sekunden
3 Stück alle 300 Sekunden
4 Stück alle 1200 Sekunden

Die Auflösung habe ich in fhem auf 9 Bit gesetzt. Alle Sensoren lassen isch auslesen/geben Temeraturwerte zurück. Der Wert LAST_READ_FAILED steht überall auf "0".

Ich bin mir ziemlich sicher, dass ich im Herbst das Problem nicht hatte. Zwischenzeitlich habe ich eigentlich nur Updates via des fhem-Updatemechanismus gemacht.
Die hohe Last ist mir nur aufgefallen, weil der CPU-Lüfter meines Boards hörbar war. Fhem ist funktioniert einwandfrei ohne jegliche Verzögerungen, schließe auch fhem eigentlich aus, da das Problem auch besteht, wenn ich owserver ohne fhem starte.

Probiert habe ich owfs-2.8p6, sowie owfs-2.9p0. Beide mit gleichen Effekt.

Hat jemand eine Idee wie ich mich dem Problem nähern könnte?
Ist das Hardware bedingt?
Warum lief es dann vorher?
Kann ich das irgendwie debuggen?
Irre ich mich und die Systemlast war schon immer so hoch?

Fragen über Fragen...

Danke & Gruß

axim

Hallo sweetie-pie,

habe exakt das gleiche Problem  :(

Hast Du zwischenzeitlich eine Lösung bzw. eine Ursache hier für finden können.

Gruß Achim

ritchie

#2
Hallo Zusammen,

anbei meine Ausgabe vom Befehl Top.
Hier sieht man eigentlich das der Rechner (cubietruck) sich mehr oder weniger langweilt.
Der OW Server hat auf einem Rasberry PI auch nie mehr als 5-10% CPU gewollt.

Der OWServer ist am Ende des Bildes zu erkennen. Meist ist der perl-server, der mehr last erzeugt.

Wie das den bei Euch aus ?

Kann es sein, das der OW Server Probleme mit dem Bus hat. Kommen und gehen Devices in der Übersicht der Devices ?

Error Counters prüfen von CRC, Search Fehler und so.
Prüft mal nach dieser Seite: http://www.fhemwiki.de/w/index.php?title=1-Wire_St%C3%B6rungsbeseitigung&redirect=no

Gruss R.

IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

axim

Hallo ritchie,

vielen Dank für Dein Feedback.
Bei mir läuft der Owfs Server auf einen Banana PI ( 1GB RAM ) unter Debian Linux 7.8.
Es läuft alles soweit völlig ruckelfrei, Die Hinweise auf der von Dir verlinkten Seite kann ich ausschließen.

Da ja sehr vielen User den OWFS Server unter raspberry pi ( der ja weniger Performance hat ) zu recht kommen, frage ich mich woher die
Last kommt. Bei Dir läuft er ja auch sehr entspannt.  ( Dein Bord, hat wohl so glaube ich 2GB RAM) aber wie gesagt, da ja viele den Server
unter raspberry pi laufen haben, tippe ich auf irgend einen Fehler.

Viel kann man ja in der owfs.conf ja nicht verstellen die die hohe CPU Last begründen würde.

Bei mir sieht es jedenfalls so aus, dass er immer zwischen 95 und 100 % läuft.

( wie hast Du dein Screenshot hier rein geklebt ? (//) )

Hast Du eine Idee?

Bin für jeden Tipp, dankbar.

Gruß Achim

ritchie

#4
Hi,

so ich habe das Bild nochmals aktualisiert. Hier sieht man besser, das Perl (4%) und der owserver (2%) die meiste CPU Zeit benötigen.

Zitat( wie hast Du dein Screenshot hier rein geklebt ? )
Ein Bild kann man einfügen, wenn man die "Erweitere Optionen" anwählt und dann eine Datei anhängt.

Versuche doch mal folgendes.

Stoppe fhem

sudo /etc/init.d/fhem stop

und schaue Dir dann die CPU Zeit an.

Wenn der owserver dann immer noch 100% hat. Restarte dieses Task auch mal.
sudo /etc/init.d/owserver  stop
sudo /etc/init.d/owserver  start

Schau Dir jetzt mal die CPU Zeit an. Diese sollte jetzt im einstelligen Prozentbereich sein.

Wenn nicht ?.. Dann muss man hier weiter sehen. Welche Konfiguration hast Du, greifst Du noch remote auf den owserver zu ?

Jetzt wieder fhem starten und prüfen wie sich die CPU Zeit ändert.
sudo /etc/init.d/fhem  start

Auch noch eine Variante:
Hast die das Attribute "Uncached" gesetzt.
Siehe mal hier:
http://forum.fhem.de/index.php?topic=10192.30


Hatte ich ganz vergessen zu Fragen:
Wie sehen den Deine Error Counters im Webinterface aus. Im Link oben wird das auch erklärt.

Gruss R.





IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

Achim

Hallo,

ich habe dasselbe Problem.
Zitattop - 23:39:28 up  5:22,  2 users,  load average: 1.02, 1.39, 1.47
Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
%Cpu(s): 32.5 us, 67.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    185904 total,   158532 used,    27372 free,    59204 buffers
KiB Swap:   102396 total,        8 used,   102388 free,    26436 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
12222 root      20   0 27920 2336 2012 R  97.0  1.3   7:00.34 owserver
12262 fhem      20   0 35616  31m 5876 S   1.6 17.4   2:34.18 fhem.pl
12250 root      20   0  4672 2476 2104 R   1.3  1.3   0:06.39 top

Wenn ich FHEM stoppe, ändert sich an der %CPU von owserver nichts. Allerdings lässt sich owserver mit/etc/init.d/owserver stopnicht stoppen. Das geht nur mit kill -9 pid(ohne -9 geht es auch nicht)

Wenn ich dann den owserver wieder starte, geht er sofort wieder auf die hohe CPU Auslastung. Die Startroutinen von owserver/owhttpd/owftpd habe ich von Martin Fischer http://www.fischer-net.de/hausautomation/haustechnik/1-wire/40-1-wire-software-unter-linux-teil-2.html. Im Internet habe ich "einfachere" Startscripts gefunden, allerdings nicht ausprobiert. Ich bin mir nicht sicher, ob es daran liegen kann.

Mein owfs.conf hat folgenden Inhalt
Zitat! server: server = localhost:4304
server: device = /dev/i2c-0
allow_other
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
server: port = raspi:4304
Celsius

Ich habe mir die neuste Version von owfs.org geholt (3.1p0), da ändert sich aber am Verhalten nichts. Kann da evtl. jemand weiterhelfen oder einen Tipp geben, wo man weiter suchen kann.

Viele Grüße
Achim

PS.: Ich habe mir die Auslastung noch nie so genau angesehen, erst nachdem ich die neue SYSMON Version eingespielt habe und die "Balkenanzeige" konfiguriert habe. Da erst ist mir aufgefallen, das die CPU Auslastung immer 100% anzeigt. Wahrscheinlich läuft mein System schon sein "Anfang" an mit diesem "Phänomen". Normal kann das aber nicht sein.
1x RPi V1, COC, 6x FHT, 1x S300TH, 2x DS18B20, 1x KS300
1x Arduino Nano mit Firmata, 2x DS2423old, 4x DS18B20, HIH5030, verschiedene Ein/Ausgangsschaltungen am Arduino
Mysensors-Seriell Gateway, Si7021, BH1750, Relais

Prof. Dr. Peter Henning

Ach, und warum kann das nicht normal sein ?

Soweit ich das mitgelesen habe, ist das ein Raspberry Pi. Die Bedienung des i2c-Bus auf dem Raspberry erfolgt - wie ?

Vorschlag: Versuchsweise Ankopplung des 1-Wire Bus an den Raspberry Pi über USB.

LG

pah

ritchie

#7
Hi,

in Deiner owfs.conf sind ein paar Zeilen, welche ich so in meiner Konfiguration nicht habe.
Welches Modul für die Kommunikation verwendest Du eigentlich ?
owserver oder "OW...." Module

Zitat
! server: server = localhost:4304
server: device = /dev/i2c-0
allow_other
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
server: port = raspi:4304
Celsius

Laut "Martin" ist die Einstellung in der owfs.conf
Zitat# setup owserver's port
server: port = 4304
# all programs BUT not owserver see this line
!server: server = localhost:4304
Hast Du die Zeile
Zitat
server: port = raspi:4304
schon immer drin oder erst seit dem Du am Testen bist ?
Bitte diese Zeile entfernen, es reicht eine Definition mit "localhost".

ZitatIm Internet habe ich "einfachere" Startscripts gefunden, allerdings nicht ausprobiert. Ich bin mir nicht sicher, ob es daran liegen kann.
Normalerweise ist der Startscript, welcher von dem Programmpaket "owserver" installiert wird, ausreichend.

ZitatIch habe mir die neuste Version von owfs.org geholt (3.1p0), da ändert sich aber am Verhalten nichts
Die Standardversion, welche über den normalen Paketmanager installiert wird, sollte hier aber ausreichen. Ich habe diese Version Testweise auch mal auf einem Raspberry PI installiert, konnte hier aber keine "gewinnbringenden" Vorteile erkennen, wenn Du nur die Standardfunktionen des owservers verwendest und nicht das Dateibasierende Ansprechen der Sensoren verwendest. Ich diesem Bereich ist der owserver wohl schon sehr stabil.

Ändere bitte die beiden Zeilen in der owfs.conf entsprechend ab und wiederholen den Test.


Edit: Ich habe aus Neugierde gerade mein Testsystem für 1-Wire Slaves aufgebaut und hier die CPU Last geprüft.
Die verwendete CPU ist ein Raspberry PI B mit 700Mhz. Siehe Anhang .

Hier meine owfs.conf.
Zitat
#server: device = /dev/ttyUSB0
server: device = /dev/i2c-1

####################### OWHTTPD #########################
http: port = 2121
####################### OWFTPD ##########################
ftp: port = 2120
####################### OWSERVER ########################
server: port = localhost:4304

Also selbst ein Raspberry sollte hier nur drüber lachen und nicht wirklich in die Knie gehen. Ich hatte noch 3 weitere USB 1-Wire Master angeschlossen an diesem Raspberry Pi und die Last war immer ähnlich. Zumindestens was das Verhalten des owservers angeht.

Gruss R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

Achim

#8
Hallo,

die Einträge in owfs.conf waren die Ursache. Ich habe die Einträge aus http://neubert-volmar.de/Hausautomation/RaspberryPi/

Jetzt ist mein Inhalt der owfs.conf folgender:
! server: server = localhost:4304
server: device = /dev/i2c-0
allow_other
http: port = 2121
ftp: port = 2120
server: port = 4304
Celsius


Die gesunkene CPU-Last
(http://forum.fhem.de/index.php?action=dlattach;topic=18521.0;attach=31703;image)

(http://forum.fhem.de/index.php?action=dlattach;topic=18521.0;attach=31695;image)

ist sehr gut an den Plots zu erkennen. Selbst ein Rückgang der CPU Temperatur ist sichtbar (eigentlich auch kein Wunder).

(http://forum.fhem.de/index.php?action=dlattach;topic=18521.0;attach=31705;image)

zur Vervollständigung sofern jemand auch diese Probleme hat:

meine Definition in der fhem.cfg ist folgende:define myOWServer OWServer localhost:4304


OWDevice verwende ich nicht. An dem I2C Bus sind 2x DS18B20 (OWTHERM) und ein 1x DS2423 (OWMULTI)

Vielen Dank für die Hilfe

Viele Grüße
Achim
1x RPi V1, COC, 6x FHT, 1x S300TH, 2x DS18B20, 1x KS300
1x Arduino Nano mit Firmata, 2x DS2423old, 4x DS18B20, HIH5030, verschiedene Ein/Ausgangsschaltungen am Arduino
Mysensors-Seriell Gateway, Si7021, BH1750, Relais

axim

#9
Guten Morgen,   ( Ich nutze den USB Adapter )

ich habe (auch) eine Lösung für das Problem finden können.
Bei mir scheint so, dass bei Bootvorgang ( wenn alles Mögliche gleichzeitig gestartet wird ) der owfs sich zu verhaspeln.

Ich habe einige Konstrukte Ausprobiert und bin mit folgender, auf eine CPU Last so wie ritchie, bei um die 1% Prozessorlast.

Ich starte zuerst owserver dann owfs und zuletzt ( wenn von  Nöten ) die owhttpd

In dieser Kunstaltion läuft der Owfs mit allen Diensten bei so um die 1% CPU, was ja schon mal recht erfreulich ist.

Man müsste dann jetzt irgend ein kleines Script basteln, das bei einem Start des Rechner, die Dienste entsprechen nach einander Startet.

Hat vielleicht einer eine Vorlage?

## >
Eine kleine andere Frage, ist schon jemanden aufgefallen, dass wenn man sein Bord vom Netzwerk trennt, andere Programme nicht mehr auf Owfs
zugreifen können! ( ich möchte meine Bord auch ohne Netzwerk nutzen, also einfach irgendwo, z.B. im Wochenendhaus wo keine Fritzbox vorhanden ist.)

localhost greift dann nicht mehr, auch ! server: server = 127.0.0.1:4304 nicht bei Verwendung von ! server: server = 127.0.1.1:4304 bin ich dem Problem
ein wenig näher gekommen aber nicht lösen können. Ich habe die Vermutung, dass das irgendwie mit der tcp6 Unterstützung zusammenhängt.

Hat sich jemand schon mal dieses Phänomen beobachten können?
## <

Gruß Achim

ritchie

Hallo,

zweimal Achim, witzig.

ZitatMan müsste dann jetzt irgend ein kleines Script basteln, das bei einem Start des Rechner, die Dienste entsprechen nach einander Startet.
Hat vielleicht einer eine Vorlage?

Nein, so wirst Du nicht glücklich.
Dein Stichwort heisst den "Run Level" .
Links mit Infos dazu:
http://rowa.giso.de/german/runlevel.html
http://jankarres.de/2014/07/raspberry-pi-autostart-von-programmen-einrichten/

Hier mein Run Level 05
Zitat
/etc/rc5.d:
README        S01motd     S03dbus         S03ntp            S04bluetooth     S06rc.local
S01armhwinfo  S01ramlog   S03haveged      S03owserver       S04cpufrequtils  S06rmnologin
S01bootlogs   S01sudo     S03hddtemp      S03rsync          S04owftpd
S01fhem       S02rsyslog  S03lirc         S03smartmontools  S04owhttpd
S01hostapd    S03cron     S03loadcpufreq  S03ssh            S05sysfsutils

Bei mir wird der "owserver" im Runlevel 5 gestartet. Hierbei wird er als S03 behandelt.

Generell müsstest Du hier nur die Reihenfolge ändern. Aber Vorsicht, Du wärst nicht der Erste, der danach
keinen Zugriff auf das System hat.

Ach ja, nochmals eine kurze Suche gestartet.
Hier im Forum ist die ganze Sache noch besser beschrieben:
http://forum.fhem.de/index.php?topic=12127.0

Das größte Problem bei der Suche ist immer der Suchbegriff. Kennt man den nicht, findet man nichts. ;)

Gruss R.
IPU662  Ipfire & Fhem (Homematic + MAX) - Produktiv
Cubietruck (1Wire - USB) - Produktiv

axim

Hallo ritchie,

ich werde Deine Vorschlag dankend annehmen. Habe zwar jetzt um erst mal das Problem zu entschärfen das mit einem shellscrip gelöst, da
ich das mit den Runlevel um wie von Dir gewarnt in Ruhe machen werde.

Nochmals vielen Dank.

Gruß Achim