Rega Stabilität
Moderator: Co-Administratoren
-
- Beiträge: 3729
- Registriert: 23.09.2017, 12:04
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 119 Mal
Re: Rega Stabilität
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.
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.
-
- Beiträge: 471
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 4 Mal
Re: Rega Stabilität
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 ...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?
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?
Viele Grüße,
debianatoe
debianatoe
-
- Beiträge: 471
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 4 Mal
Re: Rega Stabilität
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?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.
Viele Grüße,
debianatoe
debianatoe
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 34 Mal
Re: Rega Stabilität
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
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
-
- Beiträge: 3729
- Registriert: 23.09.2017, 12:04
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 119 Mal
Re: Rega Stabilität
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.
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.
-
- Beiträge: 471
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 4 Mal
Re: Rega Stabilität
Danke für den Hinweis! Bisher sieht das sehr entspannt aus: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.
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
Viele Grüße,
debianatoe
debianatoe
-
- Beiträge: 1150
- Registriert: 30.11.2013, 16:35
- Wohnort: Mordor
- Hat sich bedankt: 23 Mal
- Danksagung erhalten: 56 Mal
Re: Rega Stabilität
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.
- Roland M.
- Beiträge: 9737
- Registriert: 08.12.2012, 15:53
- System: CCU
- Wohnort: Graz, Österreich
- Hat sich bedankt: 251 Mal
- Danksagung erhalten: 1357 Mal
Re: Rega Stabilität
Hallo!
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
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
Zur leichteren Hilfestellung bitte unbedingt beachten:
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
- Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
- Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
- Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
- Fehlermeldungen genau abschreiben, besser noch...
- Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
-
- Beiträge: 268
- Registriert: 03.10.2014, 12:46
- System: CCU
- Wohnort: Enzkreis
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 43 Mal
Re: Rega Stabilität
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:
nach ReGaHss-Neustart (nicht reboot, nur /etc/init.d/S70ReGaHss restart):
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)
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)