Es ist ein normales Verhalten, dass der Cached Memory ansteigt. Leerer Arbeitsspeicher ist verschwendeter Arbeitsspeicher. Daher wird Linux niemals den Cached Memory aufräumen, solange keiner den Speicher für was wichtigeres anfragt. Wenn du meinst der müsse geleert werden, dann kannst du das wie folgt machen:
Auffällig war bisher immer, das IPS abstürzte (siehe oben im Thread) wenn der Cache -schnell- gefüllt wurde.
Und es steigt innerhalb von 1-2 Minuten extrem an, tlw. bis runter auf nur noch 6MB „Free Memory“ (siehe Bild).
Evtl. liegt hier das Problem, weil ein Anruf das Speicherfressen und die Prozessorlast startet (aber nicht immer) !
Dauert dann noch ca. 1-2 Minuten bis IPS auf Grund läuft…
bei mir steigt IPS4 ( Wind10,64Bit ) gefühlt alle 2 Std. komplett aus, da passiert nichts mehr und im Tray-Symbol kann ich „IPS starten“, was dann auch geht, aber eben nur kurze Zeit.
Den Grund hab ich bisher nicht erkennen können, vermutet aber ein Zusammenhang mit Homematic ( CCU2 ):
Schaltfunktionen oder Statusanzeigen der Homemativ in IPS gehen bei mir derzeit überhaupt nicht mehr, immer „Zeitüberschreitung“ in der web-GUI
rufe ich den Homematic Konfigurator auf um die Liste der Geräte zu aktualisieren, bekommen ich „Zeitüberschreitung“ und mehr nicht.
Falls jemand ein Idee hat, immer her damit.
IPS-Rechner und CCU hängen am selben Switch, ich hab auch nichts ander Netzkonfig geändern oder andere Software installiert.
ich habe unter Windows V4 „mehrere Abstürze“ seitdem in IPS etwas an der PHP-Verarbeitung umgestellt wurde, letzter Eintrag ist immer:
134 in scripts\IPSLibrary\app\core\IPSLogger\IPSLogger.inc.php (call IPSLogger_Out)
40 in scripts\IPSLibrary\app\core\IPSLogger\IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_Err)
121 in scripts\IPSLibrary\app\core\IPSLogger\IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_PhpErrorHandler)
in IPSLogger_PhpFatalErrorHandler
Die vorherige Zeile (mit dem fehlerhaften Script) ist immer eine andere.
Ich gehe jetzt wieder auf die Version vom 19.10.15: 6bc1b21b817c
ich habe gestern die aktuelle Version auf den Windows-Systemen und auf zwei PIs eingespielt. Die PIs laufen jetzt über 12 Stunden klaglos. Mein Windows-Backup-System scheinbar auch (tut aber auch faktisch nichts außer das Hauptsystem zu überwachen & ggf. neu zu starten).
Das Hauptsystem stürzt praktisch stündlich ab. Fehler wie ein Beitrag drüber - oder auch letzte Aktivitär Z-WAVE.
Die Version vom 19.09. lief durch.
Ich habe es sowohl mit den aktuellen php-Extensions (30.09.15) als auch mit den älteren probiert - scheinbar kein Einfluss.
So ich habe gestern auf Jessie aktualisiert, aber leider sind die Bugs mit Curl immer noch enthalten.
*** Error in `/usr/bin/symcon': double free or corruption (fasttop): 0x6ec34f98 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x755ef430 (LWP 27314)]
0x76869f50 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x76869f50 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x7686b304 in __GI_abort () at abort.c:89
#2 0x768a5900 in __libc_message (do_abort=<optimized out>, fmt=0x76958628 "*** Error in `%s': %s: 0x%s ***
") at ../sysdeps/posix/libc_fatal.c:175
#3 0x768abb2c in malloc_printerr (action=1, str=0x76958864 "double free or corruption (fasttop)", ptr=<optimized out>) at malloc.c:4996
#4 0x768acad0 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=1969140880) at malloc.c:3840
#5 0x76d2bfd0 in ?? () from /usr/lib/arm-linux-gnueabihf/libcurl.so.4
Backtrace stopped: previous frame identical to this frame (corrupt stack?)