Hallo,
nur zur Info und für mich zur Erinnerung:
Nach längerer Suche meines Performance-Fressers auf Cubietruck habe ich eine FHEM2FHEM-Anbindung gelöscht.
Dadurch reduzierte sich die Systemlast wieder auf normale Bereiche unter 10% für Perl im Leerlauf.
Vorher lag die Last bei 50-100%.
Auf meiner Suche habe ich vorher diverse unwichtige Dinge (Test-Konfigurationen) ebenfalls gelöscht, aber ohne Auswirkung auf die Systemlast.
Gruß, Stefan
Das ist aber kein typisches Verhalten von F2F.
hat bestimmt eine Loop gebaut,
mit so einer Beschreibung kann keiner etwas anfangen
Sowas kann auch passieren, wenn man FHEM2FHEM nicht genügend einschränkt (viele Devices) etc. Für genaueres müsste man wissen, wie FHEM2FHEM genau konfiguriert war. Ich vermute einen Benutzerfehler.
Hallo,
ich bin die vormalige Definition noch schuldig:
##############################
# FHEM2FHEM
define ds1_FB_FHEM_Logs FHEM2FHEM 192.168.115.130:7072 LOG:.*
Obige Einrichtung erfolgte auf meinem Haupt-FHEM 192.168.115.6 (Cubietruck) testweise, wurde dann aber doch nicht genutzt.
Unter der genannten IP #130 findet sich ein Odroid mit Test-FHEM. Dort sollte eigentlich mein zweiter CUL868 angestöpselt werden wg. Problemen mit einem USB-Hub am Haupt-FHEM.
Tatsächlich hat dies aber niemals stattgefunden, insofern lief die Definition ins Leere. An der #130 ist weder CUL noch sonst etwas angeschlossen.
Wie gesagt: Nach löschen des FHEM2FHEM fiel denn auch die Systemlast wieder auf erträgliche Werte.
Frage: Denkfehler bei mir?
Und jetzt bitte nicht lästern:
Im weiteren Verlauf entdeckte ich zusätzliche Hängepartien durch eingerichtete Foto-Speicherungen "nach Auslösen von Bewegungsmelder":
define act.ipcam124.piricarp1 notify PiriCarp1:.*on.* get ipcam124,ipcam123 image
Gespeichert wurden die Fotos auf SD-Karte am Cubietruck. Nicht verwunderlich ist, wenn das System in diesem Fall für etliche Sekunden (>10) Speicherzeit verzögert arbeitet. Blöd nur, wenn als Folge die Carport-Beleuchtung später einschaltet ->WAF gegen Null.
Gruß, Stefan
Zitat von: bsl02 am 24 November 2015, 00:33:10
##############################
# FHEM2FHEM
define ds1_FB_FHEM_Logs FHEM2FHEM 192.168.115.130:7072 LOG:.*
Damit hast du die Definition zu weit gefasst. In der Regel definiert man FHEM2FHEM für ein oder eine Gruppe von Devices, aber nicht für alle. Wenn diese Devices dann noch viele Events erzeugen, ist es logisch, dass die Systemlast hoch geht. Den Einzelfall müsste man sich natürlich eigentlich genauer anschauen, aber hier würde ich ansetzen.
Das Modul IPCAM ist nicht non-blocking. Irgendwo hier im Forum habe ich ein Codeschnipsel gepostet (in einem IPCAM-Thread), mit dem man sich trotzdem non-blocking Bilder von einer Kamera holen kann.
Hallo,
ZitatWenn diese Devices dann noch viele Events erzeugen, ist es logisch, dass die Systemlast hoch geht.
das kann ich grundsätzlich nachvollziehen.
Allerdings ist mein Remote-FHEM unter der IPNr. 130 noch quasi leer nach der Erstinstallation, sozusagen nur das Systemlog u.ä. definiert.
Habe jetzt darauf für ca. 30 Minuten den Event-Monitor mitlaufen lassen: Keine Aktionen in dieser Zeit. Insofern hätte ich am Haupt-FHEM auch keine Arbeitsüberlastung aus der Verbindung erwartet ;-)
Bei mir besteht das Last-Problem aber nicht mehr, denn meine 2 CULs nebst RFXTRX laufen jetzt ohne Unterbrechung am Haupt-FHEM (Lösung war: Stromversorgung des aktiven USB-Hubs abziehen). Und hoffentlich erinnere ich mich beim nächsten FHEM2FHEM an diesen Thread.
Bilder von Camera holen non-blocking: Dank für die Info, werde ich in den nächsten Tagen mal suchen.
/Edit: gefunden http://forum.fhem.de/index.php/topic,10772.msg326011.html#msg326011 (http://forum.fhem.de/index.php/topic,10772.msg326011.html#msg326011)
Gruß, Stefan