RAM Auslastung steigt kontinuierlich

[DerSeppel]

Nein, nichts anderes am Laufen.
Es ist ja auch nicht schlimm. Das OS versucht ja damit die Performance zu steigern indem Blöcke gecacht werden. Getreu dem Motto "Freier RAM ist nicht genutzter RAM ist verschwendeter RAM."

Dieser Speicher sollte dann eigentlich sofort frei gegeben werden sobald eine Applikation mehr Speicherplatz allokieren will. Sieht man ja auch da dran, dass der Swap noch komplett leer war.

Mich wundert nur, dass der Speicher unter "free - t“ so nicht auftaucht. Kann aber so gewollt sein.

Verhalten könnte vielleicht hardwareabhängig sein. In dem Sinne, dass der Installer das anhand der Hardwareparameter einstellt.

[DerSeppel]

gaert: Damit verbunden dann die Frage: kann man die RAM Warnung im Frontend deaktivieren? Wenn nicht, kannst du es für eine der nächsten Versionen mit auf die Roadmap nehmen?

[WagoKlemme]

Bei mir ist, seit bald einem Jahr produktiv, der Ram noch nie über 7% gegangen. Mit Edomi hat das mMn nichts zu tun. Ich tippe mal auf einen LBS der was mit mysql zu schaffen hat.

[DerSeppel]

Wie gesagt, aktuell ist nur ein LBS im Einsatz auf meinem System und der hat mit MySQL nichts zu tun. Ich schreibe auch nur ein paar Werte auf IKOs, nicht mal in ein Archiv.

Und der MySQL hat ja auch nur ca. 1 GB allokiert. Es kann wirklich sein, dass es aus dem OS kommt. Daher die Frage ob man die RAM Warnung ausschalten kann. Das versuche ich grade noch genauer zu verstehen.

Ich habe mal testweise im httpd die MaxCallsPerChild auf 10 gesetzt damit er die Prozesse nicht so lange recycled. Wenns Jetzt nicht mehr (so stark) auftritt, dann würde das meines Erachtens doch auf ein memory leak in einer PHP Applikation hinweisen. Ob LBS oder EDOMI sei mal dahin gestellt.

[jonofe]

Läuft denn ausschließlich EDOMI auf deinem Server?

[DerSeppel]

Ja.

[jonofe]

Das ist dann schon seltsam. Weil es ja noch bei keinem anderen so aufgetreten ist. Ein Memory Leak wäre dann sehr unwahrscheinlich, denn das würde sich doch bei allen bemerkbar machen. Ist es denn ein Standard LBS, den du einsetzt?

[DerSeppel]

Kein Standard LBS.
Es ist der LBS19000210 (Nibe Uplink)

Hier wird cURL eingesetzt. Hinsichtlich memory leaks wohl kein unbeschriebenes Blatt. Da setze ich grade nochmal an.

[Winni]

Hm, ich habe heute auch mal nachgesehen... Hänge auch schon bei 46%, bisher aber keine Probleme. Als Top-Verbraucher ist auch nur mySQL auszumachen, aber wie schon vorher angemerkt, die Summe der Prozesse ergibt bei weitem nicht die 46%
ram.png

Leider bin ich absoluter Linux Laie....

[DerSeppel]

In meinem Fall ist es auf jeden Fall ein memory leak im Nibe-LBS, das habe ich soweit schon raus debugt.
Vor allem das herunterschrauben der MaxRequestsPerChild hat gezeigt, dass der Speicher langsamer ansteigt.
Bin grade dabei den LBS aufzuräumen damit alle Objekte sauber deinitialisiert werden.

@Winni: Deutet ebenfalls auf ein memory leak hin.
Ich fürchte das wird bei vielen LBS der Fall sein. Welche LBS hast du denn im Einsatz?

[jonofe]

In meinem Fall ist es auf jeden Fall ein memory leak im Nibe-LBS, das habe ich soweit schon raus debugt.
Vor allem das herunterschrauben der MaxRequestsPerChild hat gezeigt, dass der Speicher langsamer ansteigt.
Bin grade dabei den LBS aufzuräumen damit alle Objekte sauber deinitialisiert werden.

@Winni: Deutet ebenfalls auf ein memory leak hin.
Ich fürchte das wird bei vielen LBS der Fall sein. Welche LBS hast du denn im Einsatz?

Normalerweise ist php da ziemlich einfach gestrickt und übernimmt selbst die Freigabe des Speichers. Problem sind im wesentlichen Zirkelbezüge zwischen Objekten. Das ist schon recht selten und wenn dann meist bei komplexen Klassen. Daher teile ich deine Befürchtung nicht. Das wäre sicher auch bei vielen EDOMI Usern aufgetreten, wenn das so wäre.

Beim NIBE kann ich mir das gar nicht vorstellen, denn das ist ja kein daemon, d.h. das Skript wird gestartet, holt die Daten und beendet sich. Da kann kein Memory Leak entstehen, da das Skript ja nur ein paar Sekunden läuft. Und danach gibt php allen Speicher wieder frei.

EDIT: ich denke das setLogicElementStatus(1); ist das Problem beim NIBE LBS, denn dadurch ruft sich der LBS ständig neu auf. und zwar solange bis es wieder am Ende des EXEC auf 0 gesetzt wird. Ich denke das sollte mit einer Variablen gemacht werden, d.h. Variable auf 1 wenn getriggert wurde und am Ende des EXEC diese Variable wieder auf 0.

[DerSeppel]

EDIT: ich denke das setLogicElementStatus(1); ist das Problem beim NIBE LBS, denn dadurch ruft sich der LBS ständig neu auf. und zwar solange bis es wieder am Ende des EXEC auf 0 gesetzt wird. Ich denke das sollte mit einer Variablen gemacht werden, d.h. Variable auf 1 wenn getriggert wurde und am Ende des EXEC diese Variable wieder auf 0.

Danke, super Hinweis! Ich schau mir mal an wofür das setLogicElementStatus überhaupt ist. Dass PHP das wohl alles selbst ganz gut bereinigt hab ich mittlerweile auch gesehen. Hab den Code mal mit memory_get_usage() instrumentalisiert.

[DerSeppel]

jonofe
Habe mal in die Doku geschaut. Wenn ich das richtig sehe ist die Implementierung eigentlich genau so wie es in der Dokumentation für setLogicElementStatus beschrieben ist. ("Beispiel: Einfacher LBSmit EXEC-Script")

function LB_LBSID($id) {

    if ($E=getLogicEingangDataAll($id)) {

        if (getLogicElementStatus($id)==0) {
            if ($E[1]['value']!=0 && $E[1]['refresh']==1) {
                setLogicLinkAusgang($id,1,0);
                setLogicElementStatus($id,1);

                callLogicFunctionExec(LBSID,$id);
            }
        } else {
            //### ggf. checken, ob Timeout erreicht wurde! Sonst "läuft" der BS ja für immer, obwohl das EXEC-Script schon längst abgekackt ist...
        }

    }

}

Der Baustein dürfte den Exec doch nur ausführen, wenn ein Wert != 0 anliegt und der Wert neu ist. Da der LBS in meinem Fall alle 30 Sekunden getriggert wird, sehe ich erst mal kein Problem.
Wenn ich das richtig verstehe entspricht dein Vorschlag ja eher dem Daemon-Ansatz aus der Doku.

[jonofe]

Hier die Beschreibung aus dem Wiki, ähnlich steht es auch in er Hilfe, aber leider kan nich gerade darauf nicht zugreifen:

Die Funktion setLogicElementStatus($id,1) startet den LBS, setzt also seinen Status auf "läuft". Dadurch wird der LBS von der Logik-Engine immer wieder aufgerufen,

Damit wird meiner Meinung nach der LBS immer wieder aufgerufen solange der EXEC Teil läuft. Eigentlich ist dies aus meiner Sicht für Timing relevante LBS nützlich. Hier geht es aber nur darum, dass der EXEC LBS nur einmal zur gleichen Zeit läuft. Dies realisiere ich in meinen LBS in der Form, dass ich eine Variable auf 1 setze, wenn ich den EXEC Teil aufrufe. Am Ende des EXEC setze ich die Variable wieder auf 0 (logic_setVar()). Und der EXEC wird nur aufgerufen, wenn die Variable=0 ist (logic_getVar()==0). Aber ich denke inzwischen, dass es nicht wirklich hier eine Ursache ist, da der LBS zwar ständig aufgerufen wird, allerdings mit den Bedingung if (getLogicElementStatus($id)==0). Daher sollte da nicht viel Schlimmes pasieren.

Hier noch mal, der oben beschriebene Ansatz

 [FONT=Arial][DEF] [/FONT][v#1 = 0] [/DEF] 
[LBS]
[COLOR=#FF0000]if (logic_getVar($id,1) == 0) [/COLOR]{
[COLOR=#FF0000]logic_setVar($id,1,1);[/COLOR]
callLogicFunctionExec(LBSID,$id);
}
[/LBS]

[EXEC]

<Code to execute>
[COLOR=#FF0000]logic_setVar($id,1,0);[/COLOR]

[/PHP]

[coliflower]

setLogicElementStatus($id,1)

Ich habe es so verstanden, dass dieser Befehl den LBS ansich immer triggert, unabhänig davon ob nur der LBS oder auch der EXEC etwas tut ... Der LBS "Blinkt" im roten Rahmen ...

Folgendes Konstrukt verhindert nur, dass erneute Triggern des EXEC, insbesondere wenn dieser als Daemon läuft ...

  if (logic_getVar($id,1) == 0) { logic_setVar($id,1,1); ... logic_setVar($id,1,0); 

Wobei das 0 am Ende gesetzt werden soll wenn der Daemon beendet wird um ein erneutes Starten zu ermöglichen.