RAM Anzeige

[KNXFan1970]

Ich hatte EDOMI jetzt einige Tage laufen, ohne Änderungen vorzunehmen. Mir ist dabei aufgefallen, dass sich die RAM Nutzung lt. Anzeige vergrößert ca. 1-2% pro Tag. Tritt dies auch bei anderen Usern auf?

[gaert]

Bei mir sind's etwa 8% direkt nach dem Booten - dann pendelt es sich bei ca. 12-15% ein (nach einigen Tagen). Grund zur "Sorge" besteht im Normalfall nicht, denn Linux nutzt das RAM ggf. auch zum caching etc. und gibt es bei Bedarf auch wieder frei. Selbst 100% wären nichts ungewöhnliches! Es sei denn, irgendein LBS dreht durch und schnappt sich ständig leckeres RAM - ohne es ordentlich wieder freizugeben. PHP räumt erst beim Beenden des Scripts automatisch auf, daher kann so ein EXEC-LBS durchaus "Schaden" anrichten... (Falls der Bursche nicht sauber implementiert ist und z.B. im ms-Takt irgendwelche Arrays deklariert o.d.G.).

Näheres verrät z.B. "top" (SSH/Konsole): Dort siehst Du wieviel RAM für's Caching etc. verwendet wird. EDOMI zeigt übrigens den Gesamtverbrauch an.

[KNXFan1970]

Danke für Deine schnelle Antwort. Einen meiner LBS hatte ich zuerst im Verdacht und hatte schon mal vorab "geprüft" was ich da so fabriziert habe. Denke aber - das kann ich ausschließen. Beobachte das Ganze mal mit 'top' weiter.

[LynnBayer]

Bei mir läuft auch der RAM über einen Tag hinweg komplett voll.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13234 root 20 0 275m 11m 6916 S 2.7 0.3 35:45.65 php
13245 root 20 0 5879m 3.3g 8260 S 2.7 92.0 39:52.78 php
1608 mysql 20 0 1103m 33m 2388 S 0.7 0.9 52:33.29 mysqld
13236 root 20 0 272m 8360 6888 S 0.7 0.2 35:50.83 php
13219 root 20 0 274m 7676 6848 S 0.3 0.2 1:39.38 php
13227 root 20 0 272m 7872 6880 S 0.3 0.2 2:41.36 php
1 root 20 0 19232 488 368 S 0.0 0.0 0:01.35 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.30 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 0:02.69 ksoftirqd/0

kann ich über die PID den LBS ausfindig machen?

Viele Grüße
Lynn

[vento66]

Hast Du den Baustein Telegram Reciver (19000304) Im Einsatz? Der füllt mir im laufe des Tages den RAM Speicher.

[Robby]

Hast Du den Baustein Telegram Reciver (19000304) Im Einsatz? Der füllt mir im laufe des Tages den RAM Speicher.

Das mir das RAM vollläuft habe ich auch....werde mal den Telegram Receiver deaktivieren und mal schauen ob es dann auch noch auftritt.
DANKE

[LynnBayer]

Ja den hab ich im Gebrauch. Kann ihn mal deaktivieren.

[jonofe]

Habe mir das mal angeschaut und die Ursache analysiert. Es handelt sich offensichtlich um ein memory leak in der php-telegram-bot API, die ich extern eingebunden habe.
Leider kann ich das Problem nicht lokalisieren, habe aber auf Github ein "ISSUE" eröffnet. Mal sehen, welches Feedback kommt.
Inzwischen habe ich ein Update des Bausteins hochgeladen. Damit ist es nun möglich über den neuen Eingang E6 den Baustein zu resetten. Eine 1 auf den Eingang E6 bewirkt einen Neustart des Baustein. Das sollte zumindest ein Work-Around sein, den man z.B. mit einem automatischen Trigger nutzen kann.
VG
André

[Robby]

Es lag wirklich nur an dem Baustein .....der RAM steht seit Stunden auf 6%........hatte schon seit Tagen gegrübelt woran es liegen würde.

Mit dem Work-Around kann man ja sehr gut leben. Ist ja so ein klasse Baustein!!!!

Nochmals Danke

[gaert]

Jetzt wisst Ihr auch, warum EDOMI keinerlei externe Klassen/APIs nutzt Ich mag keine "Fremdsoftware" - Kontrollverlust und so... Aber ich sehe natürlich durchaus ein, dass es manchmal sinnvoller ist, schließlich muss (oder kann) man das Rad nicht immer neu erfinden.

[LynnBayer]

Danke dir Andre. Werde ich heute Abend gleich testen.