Seite 3 von 3
Re: Rega Stabilität
Verfasst: 24.01.2018, 22:56
von NickHM
Guten Abend
nur so als Anmerkung ... Als die Diagrammfunktion in der CCU2 neu war, habe ich natürlich zum Testen auch so 5..10 Diagramme angelegt. Mit dem Erfolg, dass die CCU immer nur wenige Wochen lief. Dann musste ich neu starten.
Nachdem ich auf die Diagramme komplett verzichtet habe und wieder extern logge und Diagramme erzeuge (was auch deutlich mehr Komfort bietet), läuft die CCU2 deutlich länger und stabiler.
Re: Rega Stabilität
Verfasst: 24.01.2018, 23:07
von debianatoe
jmaus hat geschrieben:Na in dem Falle ist es eben java das zuviel Speicher frisst. von den max 256MB RAM verbraucht das ja bereits recht viel. Wieviel HmIP Geräte hast du denn?
Diese 173MB sind wirklich erschreckend viel, aber Bullis Java-Prozesse liegen auch ohne Diagramme und ohne HM-IP-Geräte bei 150 bzw. 167MB. Von daher frage ich mich, wie man bei diesem Java-Speicherfresser signifikant RAM sparen kann. Ich habe nur 2 HM-IP-Geräte, was wahrscheinlich auch nicht überdurchnittlich viel ist ...
Was mich an diesem Absturz außerdem wundert: der Java-Prozeß liegt tagelang stabil bei 173MB und plötzlich mitten in der Nacht geht plötzlich der Speicher aus? Warum? Welches Ereignis hat hier das (zugegebenermaßen recht volle) Faß zum überlaufen gebracht?
Re: Rega Stabilität
Verfasst: 24.01.2018, 23:13
von debianatoe
NickHM hat geschrieben:Guten Abend
nur so als Anmerkung ... Als die Diagrammfunktion in der CCU2 neu war, habe ich natürlich zum Testen auch so 5..10 Diagramme angelegt. Mit dem Erfolg, dass die CCU immer nur wenige Wochen lief. Dann musste ich neu starten.
Nachdem ich auf die Diagramme komplett verzichtet habe und wieder extern logge und Diagramme erzeuge (was auch deutlich mehr Komfort bietet), läuft die CCU2 deutlich länger und stabiler.
OK ... überzeugt: ich habe jetzt alle Diagramme entfernt. Der Java-Prozeß hat sich durch die radikale Maßnahme um ganze ZWEI MB reduziert: von 173MB auf 171MB. Vielleicht muß man den Java-Prozeß neu starten, damit sich der Effekt verstärkt?
Re: Rega Stabilität
Verfasst: 24.01.2018, 23:58
von Familienvater
Hi,
mach mal öfters ein df (Disk Free) auf der Konsole und beobachte, ob das tempFS, was nach /var gemountet ist, vollsuppt. Es gab da wohl teilweise Log-Rotationsprobleme was das HMServer-Log angeht, und dann würde das Hauptspeicher auffressen, weil das tempFS soetwas wie ein Ramdisk ist.
Der Familienvater
Re: Rega Stabilität
Verfasst: 25.01.2018, 10:02
von NickHM
Guten Morgen
mit 2 zum Test angelegten Diagrammen und ca. 10 HMIP Geräten liegt der Java Prozess bei mir bei 165MB.
Scheint so die "normale" Größenordnung zu sein.
Re: Rega Stabilität
Verfasst: 26.01.2018, 19:53
von debianatoe
Familienvater hat geschrieben:
mach mal öfters ein df (Disk Free) auf der Konsole und beobachte, ob das tempFS, was nach /var gemountet ist, vollsuppt. Es gab da wohl teilweise Log-Rotationsprobleme was das HMServer-Log angeht, und dann würde das Hauptspeicher auffressen, weil das tempFS soetwas wie ein Ramdisk ist.
Danke für den Hinweis! Bisher sieht das sehr entspannt aus:
Code: Alles auswählen
Filesystem Size Used Available Use% Mounted on
ubi0:root 169.0M 77.6M 91.4M 46% /
devtmpfs 124.6M 0 124.6M 0% /dev
tmpfs 124.7M 0 124.7M 0% /dev/shm
tmpfs 124.7M 164.0K 124.5M 0% /tmp
mediafs 124.7M 0 124.7M 0% /media
varfs 196.0M 1.5M 194.5M 1% /var
Re: Rega Stabilität
Verfasst: 11.07.2019, 19:41
von tomi_cc16
Kurze Frage, wie kann ich den die Rega Protokollierung einschalten um festzustellen was Sie zum Absturz bringt. Hab ein Protokoll nie gebraucht aber seit ein paar Wochen hängt sich immer alles nach 1-2 Tagen auf, obwohl nix geändert wurde auf der CCU.
Re: Rega Stabilität
Verfasst: 11.07.2019, 22:34
von Roland M.
Hallo!
NickHM hat geschrieben: ↑24.01.2018, 22:56
Als die Diagrammfunktion in der CCU2 neu war, habe ich natürlich zum Testen auch so 5..10 Diagramme angelegt. Mit dem Erfolg, dass die CCU immer nur wenige Wochen lief. Dann musste ich neu starten.
Diese Aussage kann ich leider - oder Gott sei Dank! - nicht unterstützen.
Auch ich habe meiner CCU2 eine Speicherkarte gegönnt und habe 14 Diagramme angelegt.
Mit wenigen Ausnahmen (Zeitumstellungs-Bug etc.) ist die CCU noch nie abgestürzt und läuft zuverlässig von FW-Update zu FW-Update (wobei ich auch da immer wieder welche überspringe).
Gerade getestet: Diagramm über die gesamte Lebensdauer der CCU (ab ca. Oktober 2014) ist komplett vorhanden!
Aber ja, mittlerweile übernahm der CCU-Historian diese Aufgabe, die CCU-Diagramme laufen aber aus Gewohnheit noch mit.
Roland
Re: Rega Stabilität
Verfasst: 12.07.2019, 11:52
von mademyday
bei mir ist es wohl immer der ReGaHss-Prozess, der den Speicher auffrisst; der java-Prozess bleibt stabil bei seinem hohen MB-Wert, auch nach x-Tagen Laufzeit:
Code: Alles auswählen
# top -b -n1
Mem: 250828K used, 4564K free, 0K shrd, 4000K buff, 51180K cached
CPU: 0% usr 7% sys 15% nic 76% idle 0% io 0% irq 0% sirq
Load average: 1.69 0.89 0.44 1/148 18193
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
18193 18148 root R N 2380 1% 23% top -b -n1
488 1 root S 163m 65% 0% java -Xmx64m -Dlog4j.configuration=file:///etc/config/log4j.xml -Dfile.encoding=ISO-8859-1 -jar /opt/HMServer/HMIPServer.jar /etc/crRFD.conf
1347 1 root S N 60368 24% 0% /bin/ReGaHss.community -f /etc/rega.conf -l 2
131 1 root S 23284 9% 0% /usr/sbin/crond
nach ReGaHss-Neustart (nicht reboot, nur /etc/init.d/S70ReGaHss restart):
Code: Alles auswählen
# top -b -n1
Mem: 209020K used, 46372K free, 0K shrd, 4304K buff, 57456K cached
CPU: 8% usr 16% sys 0% nic 75% idle 0% io 0% irq 0% sirq
Load average: 0.09 0.29 0.26 2/141 6082
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
6082 24370 root R 2380 1% 25% top -n1
488 1 root S 163m 65% 0% java -Xmx64m -Dlog4j.configuration=file:///etc/config/log4j.xml -Dfile.encoding=ISO-8859-1 -jar /o
131 1 root S 23504 9% 0% /usr/sbin/crond
24758 1 root S 21460 8% 0% /bin/ReGaHss.community -f /etc/rega.conf -l 2
# uptime
11:14:19 up 57 days, 18:54, load average: 0.10, 0.10, 0.14
durch das DataLogger-Script hier aus dem Forum logge ich div System-Werte, wie usedSytemRAM und ReGaHss-VSZ; das nutze ich für ein Script: wenn usedSytemRAM für 12h über 73% liegt, startet das Script den ReGaHss-Prozess neu, mit dem Ergebnis s.o. (das passiert mittlerweile auf meiner CCU2 alle 2-3 Wochen);
Motivation war auch bei mir, dass eines Tages mal das linux-System selbst, wg "out-of-memory" "helfend" eingegriffen hat, lt DataLogger lag da usedSytemRAM >80%
Ein Komplett-Reboot bringt noch mehr Bereinigung, dann startet das System mit ca. 45% usedSytemRAM (und das Intervall zws den ReGaHss-restarts verlängert sich wieder etwas)