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:
free && sync && echo 3 > /proc/sys/vm/drop_caches && free
Davon rate ich dir aber ab.
Hallo traxanos.
Danke für deine Unterstützung.
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).
Ich habe z.Zt. noch weitere zwei Pi’s mit IPS (gleicher SW-Stand) laufen,
da sehe ich dieses Verhalten nicht !
Kann man dieses extrem schnelle „zulaufen“ des Chache auswerten / loggen ?
Es muss doch eine Ursache für den sprunghaften Speicherge-/verbrauch geben.
Hast Du ein paar Ideen ?
Ich bin kein Linux Spezi, habe aber meinen Spass solche Fehler einzugrenzen …
Danke und Grüße
lueralba
Könntet ihr vielleicht testen, ob mit der aktuellen Version das cURL Problem noch auftritt, wenn ihr die Semaphoren weglasst?
@lueralba: Das mit den Speichersprüngen klingt auch noch nach einem Fehler. Ich wüsste ad hoc nur nicht wodurch das passieren könnte?
paresy
Hi Paresy,
also bei mir funktioniert die Version von gestern Abend sowohl auf dem Win als auch auf dem PI gänzlich klaglos.
Ciao
Herbertf
Ich habe mein Fritzbox Auslesescript (von RWN)
aktuell im Verdacht.
Habe da bei den Incoming Calls die SendMessagefunktion für Samsung TV von Nall Chan eingebaut
Nachrichten (PMR), Volume (DMR) und RC-Commandos per LAN an Samsung TV C-Serie
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…
Ich aktiviere das jetzt mal gleich wieder.
Danke, dass du dran bist 
Gruß
lueralba
Bei mir auch, habe aber noch nicht alles getestet, LCN, ZWAVE klappt ohne Probleme.
Die eigenen Module sollten auch alle gehen.
Hallo,
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 ):
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.
Hi,
also für die beiden Windows-Systeme muss ich mich leider revidieren. SInd beide jetzt schon zweimal abgstürzt - ohne sinnvolle Log-Einträge.
Meines Erachtens hängt dies mit der PHP-Änderung zusammen, (ich habe auch die ext-Files ersetzt).
In dem einen Log ist gut zu sehen, dass IPS-abstürzt aber wesentlich später den Shutdown noch schreibt…
07:53:45 | 00000 | CUSTOM | PHP | Error: Parsing Error: syntax error, unexpected 'ValueType' (T_STRING)
Error in Script - on Line 13
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
09:50:06 | 00000 | WARNING | Kernel | Service Shutdown requested!
09:50:06 | 00000 | MESSAGE | Kernel | Deinitialisiere...
09:50:06 | 00000 | MESSAGE | DataServer | Stoppe Server...
Der Fehler in der Library ist seit Version 4, hat aber vor den PHP-Änderungen keinen Effekt gehabt.
herbertf
Hi,
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
Ciao herbertf
Hi Paresy,
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.
Ciao Herbertf
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?)