Performance Probleme -Befehle werden zeitverzögert ausgeführt

[Mitch]

Hallo,

hatte schonmal in der Googlgruppe darüber geschrieben.

Ich habe ziemliche Probleme damit, dass Schaltbefehle stark verzögert (5 bis 15 Sec.) ausgeführt werden.

Meine Hardware ist ein Nettop mit Atom CPU, 1GB RAM und SSD. OS ist ein aktuelles Ubuntu.
Darauf läuft nur fhem in der aktuellsten Version.

Ich habe ein paar Wandschalter, die nicht direkt gekoppelt sind, sondern "über" fhem laufen. Wenn ich diese drücke, dauert es wie gesagt, manchmal bis zu 15 sec., bis der Schaltbefehl ausgeführt wird.
Ansonsten läuft fhem normal und stabil.

Ich hatte zum Test auch schonmal das Logging deaktiviert, hat aber nichts gebracht.

Hat jemand einen Rat für mich?

[Rohan]

Hallo Markus,

Schaltbefehle für welche Art von Schaltgeräten?

SSD und ATOM => Nadelöhr bleibt der Atom

Welches Ubuntu? Server? Läuft ein X-Server darauf

Schon mal top im Terminal eingegeben und geschaut, welche Prozesse welche Systemlast verursachen?

"swap" eingerichtet? Wird das genutzt (siehe ebenfalls "top")? Wenn ja, nicht sehr förderlich für Performance.

Nur mal so als erste Anmerkungen.

Gruß
Thomas

[Mitch]

Naja, fhem läuft auf kleinen NAS und Fritz Boxen, da sollte es locker mit einem Atom auskommen.
Ubuntu ist kein Server, v12.04 mit Grafischer Oberfläche.

Ich hatte letztes Jahr sogar noch vmware drauf und darin ein Win7 mit iTunes als Mediaserver und hatte keine Probleme mit fhem.

Irgend ein Update der letzten Monaten muss irgend etwas verändert haben und führt zu dieser Verzögerung.

Schalbefehl ist ein standrd FS20 Wandsender, der an fhem geht und dann wird von fhem eine FS20 Funksteckdose geschalten.

PS: top zeigt keine Auffälligkeiten, genügend Ressourcen verfügbar. Swap quasi gar nicht vorhanden (aber eingerichtet).

[rudolfkoenig]

Ih wuerde "attr global verbose 5" setzen, und dann untersuchen, was im fhem-log nach dem Schlaterdruecken steht.

[Rohan]

Naja, fhem läuft auf kleinen NAS und Fritz Boxen, da sollte es locker mit einem Atom auskommen.

Kein Thema, aber ...

... v12.04 mit Grafischer Oberfläche.

Die, auch wenn sie nicht läuft, Ressourcen fressen kann.

Ich hatte letztes Jahr sogar noch vmware drauf

Und... komplett deinstalliert oder wird die nur nicht mehr gestartet... letzteres frisst auch Ressourcen (z.B. Netzwerk-Devices)?

Irgend ein Update der letzten Monaten muss irgend etwas verändert haben und führt zu dieser Verzögerung.

Du machst auch Updates deines ubuntu 12.04? Was gibt dir dann die Gewissheit, dass es an FHEM liegt?

PS: top zeigt keine Auffälligkeiten, genügend Ressourcen verfügbar.

Hmmm.... eine Hardcopy sagt mehr als 8 Worte ;)

Swap quasi gar nicht vorhanden (aber eingerichtet).

"quasi gar nicht vorhanden" != nicht genutzt. Sobald auch nur auch 1 Byte geswapt wird, geht dies auf die Systemperformance.

Und btw.:
- eine SSD ist kein Garant für ein performantes System, insbesondere wenn häufig in bestehende Dateien *geschrieben* wird (=> Log-Dateien).
- hast du deine "FHEM-Anlage" in den letzten Monaten erweitert?
- wie viele LOG-Dateien führst / fährst du?

Sorry fürs nachhaken ;)

Gruß
Thomas

[kossmann]

Ich habe FHEM ebenfalls auf einer Atom-CPU laufen - genauer ein N270 mit 1,6 GHz, eine eeeBox B202. Neben FHEM läuft dort DNS, Mail, DHCP, Samba, NFS, Apache+Tomcat, Datenbanken, Medienserver, u.s.w. - aber alles, wie es sich für einen Linux-Server gehört, ohne grafische Oberfläche (wobei: es läuft sogar ein Xvfb). Der Server hat i.d.R. eine Load von 0,05.

=> FHEM läuft grundsätzlich problemlos und performant auf einer Atom-CPU... warum auch nicht, das ist nur ein bisschen Perl und würde wahrscheinlich auch auf einem alten 386 performant laufen.

Du wirst wahrscheinlich ein grundsätzliches Performance-Problem auf dem "Server" haben. Was sagt denn ein w oder top über die Load?

[Sturi2011]

Hi,

ich tippe eher auf ein Problem mit der FS20 Hardware oder dem Treiber (CUL/CUNO/...)

Gruß Andreas

[Mitch]

So hier mal die Antworten auf die Fragen:

Bei Log 5 und Druck auf den Wandtaster gibt es folgendes dazu im Log:

Code Auswählen Erweitern

2013.01.23 19:59:32 2: FS20 FS20_4eb103 toggle
2013.01.23 19:59:32 5: Triggering FS20_4eb103 (1 changes)
2013.01.23 19:59:32 5: Notify loop for FS20_4eb103 toggle
2013.01.23 19:59:32 5: Triggering act_on_FS20_4eb103
2013.01.23 19:59:32 5: Cmd: >{ if ("toggle" ne "off") { fhem("set FlurUnten on-for-timer 1 ; set FS20_4eb103 off") } }<
2013.01.23 19:59:32 5: Cmd: >set FlurUnten on-for-timer 1<
2013.01.23 19:59:32 2: FS20 set FlurUnten on-for-timer 1
2013.01.23 19:59:32 5: Sending 810a042401010143a1003904
2013.01.23 19:59:32 5: Triggering FlurUnten (1 changes)
2013.01.23 19:59:32 5: Notify loop for FlurUnten on-for-timer 1
2013.01.23 19:59:32 5: Cmd: >set FS20_4eb103 off<
2013.01.23 19:59:32 2: FS20 set FS20_4eb103 off
2013.01.23 19:59:32 5: Sending 810904050101014eb10300
2013.01.23 19:59:32 5: Triggering FS20_4eb103 (1 changes)

Wobei er beim Test mal wieder sofort reagiert hat.


vmware ist wieder deinstalliert, wobei ich absolut nicht an ein Ressourcenproblem glaube.
Wie gesagt, es geht alles in fhem nur fällt es bei dem einen Schalter extrem auf.

Ein Defekt an FHZ oder dem Wandschalter kann es auch nicht sein, weil wie gesagt andere Funktionen gehen und es nicht nur bei einem Wandschalter, sonder bei dieser speziellen "Funktion" passiert.

Log fahre ich nur für die FHTs (9 Stück), für eine Wetterstation und für Yahoowetter. Daran hat sich aber nichts geändert.

Top gibt folgendes aus (sorry für die Formatierung):

Code Auswählen Erweitern

[H [2J    [mtop - 20:09:46 up 4 days,  9:31,  2 users,  load average: 0.96, 0.39, 0.18    [m    [K
Tasks:    [m       [m 171     [m   total,    [m       [m   1     [m   running,    [m       [m 170     [m   sleeping,    [m       [m   0     [m   stopped,    [m       [m   0     [m   zombie    [m    [K
Cpu(s):    [m       [m  0.5%    [m   us,    [m       [m  0.3%    [m   sy,    [m       [m  0.1%    [m   ni,    [m       [m 99.0%    [m   id,    [m       [m  0.2%    [m   wa,    [m       [m  0.0%    [m   hi,    [m       [m  0.0%    [m   si,    [m       [m  0.0%    [m   st    [m    [K
Mem:     [m       [m  4112076k     [m   total,    [m       [m  2295600k     [m   used,    [m       [m  1816476k     [m   free,    [m       [m   560876k     [m   buffers    [m    [K
Swap:    [m       [m  4182012k     [m   total,    [m       [m        0k     [m   used,    [m       [m  4182012k     [m   free,    [m       [m  1164864k     [m   cached    [m    [K
 [6;1H
 [7m  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                [m    [K
    [m 1000 root      20   0 98968  18m  10m S   45  0.5  18:54.93 Xorg                   [m  
    [m 7510 markus    20   0 1590m  50m  10m S   23  1.3   0:37.36 TeamViewer_Desk        [m  
    [m    [m 7673 markus    20   0  2852 1168  880 R    6  0.0   0:00.04 top                    [m  
    [m12981 markus    20   0  5584 2484  688 S    6  0.1   4:05.73 wineserver             [m  
    [m12978 markus    20   0 1600m  32m  11m S    2  0.8   4:41.16 TeamViewer.exe         [m  
    [m    1 root      20   0  3768 2160 1312 S    0  0.1   0:01.83 init                   [m  
    [m    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd               [m  
    [m    3 root      20   0     0    0    0 S    0  0.0   0:06.33 ksoftirqd/0            [m  
    [m    6 root      RT   0     0    0    0 S    0  0.0   0:00.18 migration/0            [m  
    [m    7 root      RT   0     0    0    0 S    0  0.0   0:01.59 watchdog/0             [m  
    [m    8 root      RT   0     0    0    0 S    0  0.0   0:00.37 migration/1            [m  
    [m   10 root      20   0     0    0    0 S    0  0.0   0:06.43 ksoftirqd/1            [m  
    [m   11 root      20   0     0    0    0 S    0  0.0   0:04.40 kworker/0:1            [m  
    [m   12 root      RT   0     0    0    0 S    0  0.0   0:01.38 watchdog/1             [m  
    [m   13 root       0 -20     0    0    0 S    0  0.0   0:00.00 cpuset                 [m  
    [m   14 root       0 -20     0    0    0 S    0  0.0   0:00.00 khelper                [m  
    [m   15 root      20   0     0    0    0 S    0  0.0   0:00.00 kdevtmpfs


w gibt folgendes aus:

Code Auswählen Erweitern

20:13:30 up 4 days,  9:35,  2 users,  load average: 1,05, 0,83, 0,42
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
markus   tty7                      Sat10    4days 20:31   0.86s gnome-session -
markus   pts/3    :0               20:09    0.00s  0.87s  0.02s w


Also in meinen Augen scheidet folgendes aus:
1. Performance Problem HW
2. Hardwaredefekt FHZ
3. Hardwaredefekt Wandsender

Es kann eigentlich nur ein Softwareproblem in fhem sein, wobei es hier auch ein cfg Problem sein kann.

Hier der Ausschnitt aus der cfg dazu:

Code Auswählen Erweitern

define FS20_4eb103 FS20 4eb1 03
attr FS20_4eb103 alias Flur
attr FS20_4eb103 fm_name Flur
attr FS20_4eb103 fm_order 4
attr FS20_4eb103 model fs20st
attr FS20_4eb103 room Wohnzimmer

define FlurUnten FS20 43a1 00
attr FlurUnten model fs20st
attr FlurUnten room hidden

define act_on_FS20_4eb103 notify FS20_4eb103 { if ("%" ne "off") { fhem("set FlurUnten on-for-timer 1 ;; set FS20_4eb103 off") } }

define FS20_4eb123 FS20 4eb1 13
attr FS20_4eb123 alias Flur2
attr FS20_4eb123 room hidden
define act_on_FS20_4eb123 notify FS20_4eb123 {UntoggleIndirect("FS20_4eb123","FS20_4eb103","dim100%%")}

Vielleicht noch zur genauen Erklärung, was ich hier mache:

Es gibt einen Unterputz Empfänger (FlurUnten), der für eine Sekunde geschalten werden soll (dieser steuert ein Stromstoßrelais im Stromkasten an).
Die Schalter FS20_4eb103 und FS20_4eb123 sind Wnadschalter. Zusätzlich ist eine Fernbedienung auch mit FS20_4eb103 programmiert.
Alle drei sollen somit den Empfänger FlurUnten für 1 Sekunde auf ON setzten und dann geht FS20_4eb103 auf OFF (dies nur "kosmetisch" für die Web GUI).

[kossmann]

Ich kann hier nur für die Linux-Schiene reden...

Brauchst die die grafische Oberfläche wirklich? Der X-Server zieht im top 45% der CPU-Zeit. Auch wenn die Load grundsätzlich deutlich unter 0.5 liegt, scheint die Kiste in die Knie zu gehen wenn du davor sitzt (also im X-Server Fenster öffnest oder sonst etwas tust).

Du siehst sowohl im top, als auch beim w drei Zahlen. Die erste gibt (i.d.R.) die aktuelle load an, die zweite den Durchschnitt der letzten 5 Minuten und die dritte den Durchschnitt der letzten 15 Minuten. Ich vermute einfach mal, dass du dich frisch (z.B. vor 3 Minuten) ran gesetzt und auf der grafischen Oberfläche ein paar Fenster geöffnet hast - dies sieht man deutlich.

Wenn die Zeit-Probleme auftreten und du davor sitzt, kann dies ein Grund sein.

Ich glaube jedoch auch an ein anderes Problem. Obiges solltest du dir nur mal durch den Kopf gehen lassen, wenn die Kiste noch andere Dinge machen soll. Wenn die CPU nur einen Kern haben sollte, ist 0.96 schon hart an der Grenze.

[Rohan]

Hallo Markus,

habs mal etwas bereinigt:

Code Auswählen Erweitern


PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1000 root    20   0 98968  18m  10m S   45  0.5  18:54.93 Xorg
 7510 markus  20   0 1590m  50m  10m S   23  1.3   0:37.36 TeamViewer_Desk
 7673 markus  20   0  2852 1168  880 R    6  0.0   0:00.04 top
12981 markus  20   0  5584 2484  688 S    6  0.1   4:05.73 wineserver
12978 markus  20   0 1600m  32m  11m S    2  0.8   4:41.16 TeamViewer.exe


Ich weiß ja nicht, was du hast, aber 76 % CPU für Dienste / Programme (von top jetzt abgesehen), die mit FHEM nix zu tun haben?

Setz doch mal da an.

Gruß
Thomas

[Mitch]

ok, Danke schonmal.
Das leuchtet mir schon ein.

Was mich dabei nur wundert, es lief ja anstandslos und es wurde im Prinzip nicht geändert.
Ausserdem tritt der "Fehler" nicht immer auf.

Zum Linux, ja ich brauche die X Oberfläche, bin quasi Linux DAU :-)
Bin ein Apple User (und Windoof zwangsläufig im Büro).
Ich brauch bunt klicki klicki ;-)

Ansonsten habe ich die Kiste nur für fhem angeschaft und sonst soll die nichts machen.
Ich hab noch Teamviewer drauf, weil ich damit von überall (Büro, Iphone, Ipad) auf die Kiste zugreifen kann.
Deswegen auch die 23% CPU Load beim Teamviewer, weil ich über diesen zugegriffen habe, um top auszuführen.
An der Kiste ist kein Monitor oder Tastatur.

Noch zur Info, es handelt sich um diesen Nettop: Foxconn Nettop-nT435 Barebone (Intel D425, 1,8GHz, DDR3 Speicher, SATA II, 4x USB 2.0)

[Rohan]

... Ich brauch bunt klicki klicki ;-)

Spricht ja auch nix gegen ;)

Aber bitte... das heißt Windows und nicht Windoof ;)

... Ich hab noch Teamviewer drauf, weil ich damit von überall (Büro, Iphone, Ipad) auf die Kiste zugreifen kann.
Deswegen auch die 23% CPU Load beim Teamviewer, weil ich über diesen zugegriffen habe, um top auszuführen.

Und wegen TeamViewer hast du wine drauf und wegen wine hast du X drauf ....

An der Kiste ist kein Monitor oder Tastatur.

Was kein Brot frisst.

Tipp: Schaff dir 'n RPi an, der nur für FHEM da ist. Auf den kannst du von deinem Atom-PC zugreifen. Investition ~ 40,-- EUR + geringer Stromverbrauch.

Gruß
Thomas

[kossmann]

... aber da machst du doch auch nichts anderes, als eine Konsole/Terminalfenster auf, oder? Auf die Weboberfläche von FHEM kommst du auch vom Apple-Schrott. Eine grafische Oberfläche nur für (ggf.) einen Editor wäre Wahnsinn.

Eine SSH-Verbindung vom Büro nach Hause ist übrigens die sicherste Variante (behaupte ich mal) - da landet man halt auch "auf der Konsole".

Wenn du in den nächsten Tagen/Wochen mal Zeit findest, beschäftige dich mal mit der Konsole und den Möglichkeiten, Dinge dort zu machen, die du sonst auf der Klicki-Klicki-Oberfläche machst - eventuell auch auf einer virtuellen Testmaschine. Das ist alles kein Hexenwerk - wenn man die ersten Schritte erst mal hinter sich hat, geht´s immer einfacher voran.

Solltest du den X-Server mal abschalten können, hast du einen performanten Linux-Server und kannst ihn immer weiter ausbauen (siehe mein Beispiel).

[kossmann]

Und wegen TeamViewer hast du wine drauf und wegen wine hast du X drauf ....

FULL ACK :-)

[kossmann]

Und wegen TeamViewer hast du wine drauf und wegen wine hast du X drauf ....

FULL ACK :-)

... obwohl - Teamviewer gibt´s auch für Linux. Wofür WINE? Du hast in der Tat eine TeamViewer.exe laufen. Guck mal, ob du nicht wenigstens die Linux-Version zum Laufen bekommst, dann kannst du WINE schon mal deaktivieren. Es gibt fertige DEB-Pakete für Ubuntu.

[borsti67]

[quote title=kossmann schrieb am Mi, 23 Januar 2013 21:30][quote title=kossmann schrieb am Mi, 23 Januar 2013 21:26]

Teamviewer gibt´s auch für Linux. Wofür WINE?

Da muss ich Dich enttäuschen. Zumindest die aktuelle Beta basiert (immer noch?) auf WINE...

[kossmann]

Tatsache, ich habe gestern nur die DEBs gesehen ohne sie näher zu betrachten. Dann nehme ich den Teil meiner Antwort natürlich zurück ;-)

[Mitch]

Danke euch. Ich werde mir mal überlegen, ob die die X-Oberfläche runter schmeiss.

Also Teamviewer gibt es nicht als "echtes" Linuxprogramm, nur die Wine Version.

Grundsätzlich brauche ich keine graphische Oberfläche auf dem Ding. Wie gesagt, es läuft nur fhem drauf und es wird und soll auch nichts dazu kommen.

Grundsätzlich mache ich sowieso alles auf der Weboberfläche von fhem, somit läuft das Nettop einfach so vor sich hin.
Ich schau nur alle paar Wochen mal mit Teamviewer drauf, ob es Linux Updates gibt und installier die. Fertig.

Ich bin aber bzgl. meines Fehlers immer noch der Meinung, dass es kein Problem vom Nettop oder Linux ist.

[rudolfkoenig]

>  Ich bin aber bzgl. meines Fehlers immer noch der Meinung, dass es kein Problem vom Nettop oder Linux ist.

Ich auch nicht.


>  Bei Log 5 und Druck auf den Wandtaster gibt es folgendes dazu im Log:
...
>  Wobei er beim Test mal wieder sofort reagiert hat.

Ich praezisiere die Frage: Ich wuerde gerne ein fhem-Log im Fehlerfall sehen (ich dachte das ist klar :)

[Hoppaz]

Nur ganz kurz ein piep...

Ich lasse fhem in lxc (Linux container) laufen.
Am Rechner hängt ein fhz1300pc.

Im Haus sind zur Zeit 4 Rolladensteuerungen, div Schaltsteckdosen und 8Heizungssteuerungen verteilt. Bis gestern ca 17:30 alles fein. Seitdem auch männliche Probleme... Ich sende einen Befehl und dieser kommt verzögert bis garnicht an. Die fhz1300 blinkt in dem Fall auch nicht. Interessant ist, dass ich auch ubuntu 12.04 (jedoch als Server) nutze. Ich versuche nachher mal ein bisschen zu analysieren... soweit es die Kinder zulassen :-)

Könnte so ein Verhalten auch durch LTE verursacht werden, oder müsste man dann zumindest Aktion am fhz1300 sehen (blinkende LED)?

Gruß,
Lars

[Hoppaz]

Ich habe jetzt mal ein bischen probiert.

Ich nutze phyFHEM und komischerweise wird das Datum in den FHTs nicht mehr aktualisiert.
Beim debuggen ist mir aufgefallen, daß scheinbar nur noch die näheren FHTs (80B-2) an die fhz melden.
Zur Probe habe ich das Teil aus dem Wohnzimmer, was nicht mehr zu sehen war direkt daneben gelegt und siehe da, es kamen wieder Meldungen im fhem an (2013.01.27 11:25:13 4: FHT Thermostat.Wohnzimmer actuator: 34%).

Dann habe ich mir mal eine Handfernbedienung genommen und gedrückt. 5m Luftlinie mit Wand dazwischen funktioniert nicht, jedoch direkt neben der FHZ. Das Bedienen einer Funkschaltsteckdose mit der Handfernbedienung sieht ähnlich schlecht aus (irgendwas scheint das Signal zu stören) - im Hause hat sich aber nichts geändert.

Beim Aussenden von Signalen sieht es so aus: Per phyFHEM habe schalte ich eine Steckdose:
2013.01.27 11:42:41 4: Connection accepted from 127.0.0.1:38888
2013.01.27 11:42:41 5: Cmd: >set WBeleuchtung.Kueche on<
2013.01.27 11:42:41 2: FS20 set WBeleuchtung.Kueche on
2013.01.27 11:42:41 5: Sending 8109047401010100600011
2013.01.27 11:42:41 5: Triggering WBeleuchtung.Kueche (1 changes)

Das kommt direkt im FHEM an. Jedoch wird die Steckdose verzögert angeschaltet (grad geht es). Das Senden (Sending) sehe ich auch immer im Logfile, auch wenn das Signal nicht an der Dose ankommt.

Hmm.... Bei den Steckdosen und Rolladensteuerungen scheint es aktuell verzögert zu funktionieren.
Die FHTs scheinen nur im Nahbereich zu funktioieren.

Aus dem Bauch raus würde ich erstmal sagen, daß es an LTE liegen könnte.... ;-)

Hat noch jemand eine Idee?

Lars