RAM Auslastung steigt kontinuierlich

[jonofe]

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 ...

Genau so ist es!

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.

Und so würde es für den NIBE LBS reichen, da kein Timing relevantes Verhalten im LBS Bereich notwendig ist.

[DerSeppel]

Also der Exec Teil wird wie erwartet nur alle 30 Sekunden ausgeführt, das habe ich durch Ergänzung um Individual-Log Ausgaben schon herausgefunden.
Auch bei den Aufrufen tut sich am Rückggabewert von memory_get_usage() nicht viel/gar nichts.
Trotzdem sehe ich ca alle 30 sekunden, dass der RAM kurz ansteigt und dann wieder weniger wird. Bei jedem Peak scheint aber ein bisschen was im Speicher zu bleiben.

Ich probier es mal so wie beschrieben und berichte weiter.

[DerSeppel]

So, habe gestern mal den LBS umgebaut, wie von euch vorgeschlagen - keine Änderung hinsichtlich des Speichers.

Mir wird jetzt durchgehend nur ein laufender LBS angezeigt und nicht alle 30 Sekunden zwei. Von daher scheint ihr recht zu haben, bzgl. der Mehrfachaufrufe.

Dennoch sehe ich, dass alle 30 Sekunden der LBS in der Prozessliste auftaucht und der RAM-Verbrauch ansteigt. Er fällt dann wieder ab, aber nicht auf den Wert der vor der Ausführung abzulesen war. Es bleiben etwas über 1,5MB übrig - recht viel. Ich kann mir vorstellen, dass da Reste der per cURL geladenen Seite im Speicher bleiben.

Habe im EXEC am Ende mal unset() für alle großen Objekte gemacht. Ohne großen Effekt. memory_get_usage() scheint nicht wirklich zielführend zu sein, da es wohl nur den Speicher des aktuellen Prozesses zurück gibt. Daher ist der Wert bei jedem Durchlauf des LBS gleich. Um das wirklich einzugrenzen müsste man vermutlich /usr/local/edomi/main/proc/proc_queue.php instrumentieren. Das geht aber wegen bcompiler nicht.

Ich habe jetzt mal am Anfang des LBS ein gc_enable(); eingefügt, und am Ende dann gc_collect_cylces();
Mal sehen ob das was bringt. Bin mir nicht sicher ob der GC Objekte mitnimmt, die durch ein leak verschwunden sind.

[jonofe]

Ich kann mir kaum vorstellen, dass das EXEC Skript dieses Verhalten verursacht. Denn es ist ein eigenständiger php Prozess der am Ende beendet wird. Danach sollte der gesamte benutzte Speicher ans Betriebssystem zurückgegeben werden. Genau dieses Verhalten nutze ich beim Telegram Receiver LBS aus, der bekanntlich in der verwendeten Library ein Memory Leak hat. ich beende den EXEC Daemon und starte ihn sofort wieder und das Problem ist gelöst.

Wie misst du denn die 1,5 MB?

[Winni]

Ich hatte die letzten Tage mal ein Auge auf meinem RAM.... Ich start bei ca. 6-8%, bleibt dann alles auch stabil, aber mit jedem Edomi Neustart kommen so 2-3 Prozent dazu. Mittlerweile bin ich wieder auf 22%. Wie suche ich denn da am Besten? Wenn ich den Server komplett durchstarte (ist keine VM) bin ich wieder bei 6-8%.
Alle Community LBS aufzuzählen wäre ne ziemlich lange Liste.....

[DerSeppel]

Also hier nochmal ein Zwischenstand.

Um ein paar Experimente zu machen, habe ich mir ein Programm geschrieben, welches Schrittweise versucht, soviel Speicher wie möglich zu allokieren. So lange, bis keiner mehr frei ist und das Programm vom OOM Manager gekillt wird. (Im Stile von http://www.linuxatemyram.com/)

Was mir dabei aufgefallen ist:
- Der RAM wird tatsächlich als belegt angezeigt, taucht also nicht als cached/buffered auf.
- Wenn ich das o.g. tool laufen lassen, holt es sich allen noch verbliebenen RAM (in Summer aber mehr als angeblich noch frei ist!), wird gekillt und gibt dabei seinen Speicher frei. Nach dieser Aktion steht der RAM wieder bei 3% statt wie vorher beispielsweise bei 80%.

Zusätzlich habe ich folgendes feststellen können:
- Es scheint nicht an LBS zu liegen. Wenn alle Logiken deaktiviert sind, tritt der Effekt auch auf.
- Wenn Edomi pausiert ist, tritt der Effekt nicht auf.

Würde für mich erst mal auf ein Memory-Leak innerhalb Edomis hinweisen. Warum das sich bei anderen nicht manifestiert, kann ich leider nicht beurteilen.
Werde mit leben und einfach per Cron einmal am Tag RAM freigeben.

[gaert]

Ein Memory-Leak in EDOMI kann ich zu 99,9% ausschließen - denn erstens verhindert PHP dies prinzipiell, zweitens wird i.d.R. der Speicher grundsätzlich wieder "freigegeben" (vom Code her) und drittens braucht EDOMI (also der PHP-Teil) so gut wie kein RAM (fast alles läuft über mySQL).

Meine Test-Installation läuft seit Monaten(!) in einer VM mit konstanten 12% RAM-Verbrauch...

[vento66]

Ich tippe auch mal auf die allseits bekannten..

[DerSeppel]

Was wären denn die "allseits bekannten", wenn keine Logikseite aktiv ist?

[gulp2k]

Gibts hierzu noch irgendein Update?
Ich habe ein ähnliches Phenomen das bei mir der Ram konstant bei ca 88% ist. Größter Ram fresser laut top it MySQLmit ca 8%, was ja nicht viel ist...
Die Gelbe RAM Warnung bekomme ich lustigerweise auch nur auf dem IPad angezeigt,
In Chrome auf dem Computer kommt Sie nicht...

[DerSeppel]

Nein, konnte es nicht abstellen. Tippe eher auf ein Problem im Kernel.
Ich leere jetzt einmal pro Tag den RAM per Trigger aus Edomi.

[gulp2k]

Wie das?

[DerSeppel]

Sorry, hatte nicht gesehen, dass hier eine Antwort drin war. So hab ichs gemacht:

- Unter Konfiguration > HTTP/UDP/SHELL auf "Neu" klicken.
- Name: "RAM Cache leeren", URL/Shell Befehl mit Pfad: "/bin/echo 3 > /proc/sys/vm/drop_caches", Typ "SHELL"
- Speichern
- Im Logikeditor eine neue Logik angelegt. Da einfach nur eine Ausgangsbox rein.
- Befehl: "HTTP/UDP/SHELL: Ausführen", da den neuen Befehl selektieren.
- Auf den Eingang des Ausgangsbausteins klicken und das System KO "Trigger: Täglich 00:00:00" auswählen.

Damit wird einmal pro Tag der Cache geleert.

Meld dich bei Fragen.

[gulp2k]

Danke!

Das hat geklappt, heißt für mich jetzt aber auch das es Caches sind die voll sind und das ist ja auch gut so...
Werde die Situation mal beobachten.

[DerSeppel]

Prinzipiell ist das gut, ja.
Aber der Kernel scheint ein Problem zu haben. Die Werte die das OS liefert sind falsch. Zumindest in meinem Fall.