Rega Stabilität

Einrichtung, Anschluss und Programmierung der HomeMatic CCU

Moderator: Co-Administratoren

NickHM
Beiträge: 3729
Registriert: 23.09.2017, 12:04
Hat sich bedankt: 65 Mal
Danksagung erhalten: 119 Mal

Re: Rega Stabilität

Beitrag von NickHM » 24.01.2018, 22:56

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.

debianatoe
Beiträge: 471
Registriert: 05.12.2016, 19:04
Hat sich bedankt: 30 Mal
Danksagung erhalten: 4 Mal

Re: Rega Stabilität

Beitrag von debianatoe » 24.01.2018, 23:07

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?
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

Beitrag von debianatoe » 24.01.2018, 23:13

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?
Viele Grüße,
debianatoe

Familienvater
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

Beitrag von Familienvater » 24.01.2018, 23:58

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

NickHM
Beiträge: 3729
Registriert: 23.09.2017, 12:04
Hat sich bedankt: 65 Mal
Danksagung erhalten: 119 Mal

Re: Rega Stabilität

Beitrag von NickHM » 25.01.2018, 10:02

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.

debianatoe
Beiträge: 471
Registriert: 05.12.2016, 19:04
Hat sich bedankt: 30 Mal
Danksagung erhalten: 4 Mal

Re: Rega Stabilität

Beitrag von debianatoe » 26.01.2018, 19:53

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
Viele Grüße,
debianatoe

tomi_cc16
Beiträge: 1150
Registriert: 30.11.2013, 16:35
Wohnort: Mordor
Hat sich bedankt: 23 Mal
Danksagung erhalten: 56 Mal

Re: Rega Stabilität

Beitrag von tomi_cc16 » 11.07.2019, 19:41

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.

Benutzeravatar
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

Beitrag von Roland M. » 11.07.2019, 22:34

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! :)

tempverlauf.PNG
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:
  • 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,...

mademyday
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

Beitrag von mademyday » 12.07.2019, 11:52

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);

RAM-used.png
RAM-ReGaHSS-VSZ.png

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)

Antworten

Zurück zu „HomeMatic Zentrale (CCU / CCU2 / CCU3 / Charly)“