HMIPServer zieht viel CPU

[derrapf]

Hallo alle
Zum Watchdog siehe hier:
viewtopic.php?f=41&t=31581

Er fährt die CCU nicht bei jeder Kleinigkeit herunter sondern echt wenn sie fast steht.
Das merke ich z.B. an erheblichen Verzögerungen bei Befehlen über Alexa, oder bei Tastendrücken die irgendwelche Makros schalten wie "alle Lichter aus" und ähnliches. Auch jetzt, wenn ich in das WebUI gehe ist es sehr träge und ich bekomme die Meldung "eine Komponente reagiert nicht"
Und der Watchdog hat noch nicht rebootet. Die CCU muss also schon ziemlich stehen bis er sie runterfährt.

Achso und der Historian läuft auf meinem Synology NAS

Gruss Ralf

[blackbasket]

Hallo zusammen,

bei mir ist diese Nacht um 0200 wieder alles stehen geblieben. Bin gestern vor einer Woche von "eQ-3" 3.55.10 auf RM 3.55.10.20210213 umgestiegen. Ich verstehe es nicht. Absturz alle 7 Tage + ein paar Stunden.

Anbei einmal das output von top heute Morgen:

Code: Alles auswählen

Mem: 768184K used, 212572K free, 5572K shrd, 21788K buff, 269956K cached
CPU:  25% usr   0% sys   0% nic  73% idle   0% io   0% irq   0% sirq
Load average: 1.00 1.00 1.00 4/240 24600
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  969     1 root     S    3491m 363%  25% java -Dos.arch=aarch64 -Xmx128m -DlibNRJavaSerial.userlib=/opt/HMServer/libNRJavaSerialv8.so -Dlog4j.configuration=file:///etc
 1370     1 root     S    16896   2%   0% /usr/bin/monit -Ic /etc/monitrc
  342     1 root     S     293m  31%   0% /usr/sbin/rngd -q
 1092     1 root     S    47372   5%   0% /bin/ReGaHss -f /etc/rega.conf -l 2
  838     1 root     S    24772   3%   0% /bin/rfd -f /var/etc/rfd.conf -l 5
  788     1 root     S    10556   1%   0% /usr/sbin/snmpd -Lsd -Lf /dev/null -c /etc/snmp/snmpd-global.conf -I -smux mteTrigger mteTriggerConf -p /var/run/snmpd.pid
  257     1 root     S     4636   0%   0% /bin/hss_led -l 6
 1356     1 root     S     3616   0%   0% /usr/sbin/crond -f -l 9
24586 24584 root     R     3616   0%   0% top
  746     1 root     S     3152   0%   0% /usr/local/addons/cuxd/cuxd
  555     1 root     S     2020   0%   0% /usr/sbin/ifplugd -i eth0 -fwI -u0 -d10
   10     2 root     IW       0   0%   0% [rcu_preempt]
   25     2 root     SW       0   0%   0% [ksoftirqd/3]
16885     2 root     IW       0   0%   0% [kworker/2:2-eve]
22214     2 root     IW       0   0%   0% [kworker/3:2-eve]
24297     2 root     IW       0   0%   0% [kworker/0:3-eve]
  332     1 root     S    78520   8%   0% /usr/sbin/irqbalance
  284     1 root     S    15828   2%   0% /sbin/udevd -d
24600   284 root     S    15828   2%   0% /sbin/udevd -d
  805     1 root     S<   12208   1%   0% /bin/multimacd -f /var/etc/multimacd.conf -l 5
  673   672 root     S    11356   1%   0% /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf -D
 1143     1 root     S     7840   1%   0% /opt/mh/openvpn --daemon --config /usr/local/etc/config/addons/mh/client.conf --cd /usr/local/etc/config/addons/mh
24558   692 root     S     7268   1%   0% sshd: root@pts/0
  692     1 root     S     7268   1%   0% sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups
  665     1 root     S     4328   0%   0% /bin/eq3configd
  682     1 root     S     4144   0%   0% /bin/ssdpd
24584 24558 root     S     3616   0%   0% -sh
  392     1 root     S     3480   0%   0% /sbin/syslogd -n -m 0 -s 4096 -b 1 -D
    1     0 root     S     3480   0%   0% init
  395     1 root     S     3480   0%   0% /sbin/klogd -n
 1371     1 root     S     3480   0%   0% init
  104     1 root     S     3348   0%   0% /sbin/watchdog -T 300 -t 5 /dev/watchdog
   98     1 root     S     3292   0%   0% /usr/bin/psplash -n
  569     1 root     S     3104   0%   0% /usr/sbin/chronyd
  355     1 dbus     S     3044   0%   0% dbus-daemon --system
  560     1 root     S     2020   0%   0% /usr/sbin/ifplugd -i wlan0 -wI -u5 -d5
  672     1 root     S     1760   0%   0% /usr/sbin/lighttpd-angel -f /etc/lighttpd/lighttpd.conf -D
   75     2 root     IW<      0   0%   0% [kworker/1:1H-mm]
   80     2 root     IW<      0   0%   0% [kworker/3:1H-mm]
   73     2 root     IW<      0   0%   0% [kworker/2:1H-mm]
   72     2 root     IW<      0   0%   0% [kworker/0:1H-kb]
    9     2 root     SW       0   0%   0% [ksoftirqd/0]
   15     2 root     SW       0   0%   0% [ksoftirqd/1]
   20     2 root     SW       0   0%   0% [ksoftirqd/2]
   65     2 root     SW<      0   0%   0% [vchiq-slot/0]
16626     2 root     IW       0   0%   0% [kworker/1:0-mm_]
   89     2 root     SW       0   0%   0% [jbd2/mmcblk0p3-]
   24     2 root     SW       0   0%   0% [migration/3]
   11     2 root     SW       0   0%   0% [migration/0]
   14     2 root     SW       0   0%   0% [migration/1]
   19     2 root     SW       0   0%   0% [migration/2]
    2     0 root     SW       0   0%   0% [kthreadd]

Es gibt keine Programme, die nur alle 7 Tage laufen.

BTW: Watchdog hat bei mir gar nichts gemacht. Ich habe die RM gerade manuell neu gestartet.

Hilfloser Gruß
Marcel

[blackbasket]

Ich habe in messages noch Fehlermeldungen gefunden, die ich nicht interpretieren kann. Kann mir jemand helfen?

Code: Alles auswählen

Feb 21 03:37:01 MBCCU01 user.err kernel: [636931.435067] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 28
Feb 21 03:37:13 MBCCU01 user.info kernel: [636931.435073] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:37:13 MBCCU01 user.err kernel: [636943.788341] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 29
Feb 21 03:37:22 MBCCU01 user.info kernel: [636943.788355] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:37:22 MBCCU01 user.err kernel: [636952.498460] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 42
Feb 21 03:37:22 MBCCU01 user.info kernel: [636952.498480] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:37:22 MBCCU01 user.err kernel: [636952.590678] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 39
Feb 21 03:37:22 MBCCU01 user.info kernel: [636952.590692] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:37:22 MBCCU01 user.err kernel: [636952.672395] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 42
Feb 21 03:37:47 MBCCU01 user.info kernel: [636952.672409] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:37:47 MBCCU01 user.err kernel: [636977.530374] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 29
Feb 21 03:38:34 MBCCU01 user.info kernel: [636977.530386] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:38:34 MBCCU01 user.err kernel: [637025.387980] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 42
Feb 21 03:38:58 MBCCU01 user.info kernel: [637025.387993] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:38:58 MBCCU01 user.err kernel: [637049.029902] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 28
Feb 21 03:39:02 MBCCU01 user.info kernel: [637049.029916] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:39:02 MBCCU01 user.err kernel: [637053.066281] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 28
Feb 21 03:39:23 MBCCU01 user.info kernel: [637053.066293] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:39:23 MBCCU01 user.err kernel: [637074.254249] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 30
Feb 21 03:39:26 MBCCU01 user.info kernel: [637074.254262] eq3loop: eq3loop_write_master() return error: -14
Feb 21 03:39:26 MBCCU01 user.err kernel: [637076.489964] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 5, required space = 28

LG,
Marcel

[Mutze]

Guten Morgen,
ich kann die Fehlermeldungen zwar nicht interpretieren, habe jedoch seit Ende Januar die gleichen Meldungen in meinem Log was zu einem Absturz alle 4 Tage führt.
Habe hierzu auch letzte Woche eine Anfrage im Forum gestellt. (nach eq3loop suchen).

Ich habe die Hoffnung, dass es eventuell mit dem Historian zusammenhängt. Nachdem ich den Eintrag geöffnet habe ist mir aufgefallen, dass ich 4 Tage vor dem ersten Absturz auf die 2.5.3 Version vom Historian gewechselt habe. Ich habe jetzt diese Woche ein downgrade auf die 2.5.2 gemacht. Noch bin ich unter dem 4 Tages Rhythmus. Endet heute Abend. Zur Zeit sieht alles normal aus und auch keine Fehlermeldungen im Log.
Ich muss allerdings auch dazu sagen, dass ich letztes Wochenende auf die 3.55.10 gewechselt bin.
Hoffentlich läuft die CCU3 jetzt wieder stabil und die Vermutung das es der Historian war / ist bleibt bestätigt sich.
Viel Glück!

[blackbasket]

Hallo Mutze,

die Hoffnung auf Historian hat sich bei mir heute erledigt -.-
Ich drück dir die Daumen. Gefühlt besteht das Problem seit 3.55.5 - bin mir aber nicht ganz sicher.

LG,
Marcel

[Mutze]

Die 3.55.5 lief bei mir fast 30 Tage stabil.
Ich habe auf die Version direkt nach dem Erscheinen im Dezember gewechselt. Am 22.1.21 habe ich auf die Historian 2.5.3 gewechselt und am 26.1. ist die CCU erstmals stehen geblieben. Ob mit den Fehlermeldungen kann ich nicht genau sagen, da ich zu dem Zeitpunkt noch keinen Syslog aktiviert hatte.
Ich melde mich morgen noch einmal mit einem Zwischenstand. Wenn keine Besserung eingetreten ist, dann müsste die CCU3 spätestens heute Nacht wieder stehen bleiben. Bisher sieht jedoch alles i.O. aus.

[Tibin]

Wenn ich das richtig sehe läuft der Historian bei euch allen auf der Synology??
Wäre es jetzt eine schlechte Idee, wenn einer den Historian mal abschaltet? Nur um zu schauen ob die Abstürze bleiben, und ihn als Verursacher auszuschließen....
Bei mir kam das 2019 auch so alle 4-10 Tage vor (ich hatte das in Mutze's Thread schon geschrieben) Ich hatte ihn auch abgeschaltet ( auf der Synology) oder gelöscht, aber die Fehlerursache konnte ich damit nicht beheben. Es wäre vielleicht hilfreich, wenn das einer von euch bestätigen oder widerlegen könnte.
Gruß Tino.

[derrapf]

Hallo alle
Ich habe den Historian am 17.2 mal abgeschaltet, weil ich es wissen will. Ich werde berichten wenn ich Zusammenhänge finde. Mal sehe ob die CCU2 jetzt durchläuft.
Am 20. wurde sie wieder rebootet, aber ich geb' ihr trotzdem noch ne Chance und lasse sie mal ein, zwei Wochen ohne den Historian laufen. Mal sehen ob sich was ändert.

Ich habe in einem anderen Thread (viewtopic.php?f=38&t=24115&p=646316#p646316) bei dem der Historian bei mir immer mal wieder die Aufzeichnung stoppt noch folgenden Hinweis von Matthias bekommen:

Zitat:
"Ein aktiver CUxD-Timer produziert wohl jede Sekunde 7 Events. Da bin ich auch überrascht. Der Datenpunkt TS ändert sich jede Sekunde. Der Datenpunkt TIMER_GET feuert sogar zwei Events pro Sekunde. Die anderen Datenpunkte ändern ihren Wert nicht, feuern aber trotzdem Events. Ich sage mal, die CUxD-Timer versorgen den CCU-Historian und natürlich auch die ReGaHss der CCU sehr großzügig mit Events. Ich will lieber nicht an 10 aktive Timer denken.

Also am besten nur die wirklich benötigten Datenpunkte eines CUxD-Timers aufzeichnen, und dann auch mit Delta-Komprimierung oder beim Datenpunkt TS mit Swinging-Door-Vorverarbeitung."

D.h. prüft mal ob ihr CUxD Timer habt und schaltet die mal im Historian ab. Ev. hilft es. Schaden kann es sicher nicht.



Gruss Ralf

[blackbasket]

Wenn ich das richtig sehe läuft der Historian bei euch allen auf der Synology??

Hallo Tino,

bei mir läuft der Historian auf Windows 2019. Wenn's bei Mutze die nächsten Tage weiterhin läuft, werde ich aber ggf. dann auch nochmal downgraden. Ich hatte den Historian - nachdem das Problem 2x aufgetreten ist - erst von 2.2.0b4 auf 2.5.3 geupdated. Ich weiß langsam wirklich nicht mehr weiter *heul*

D.h. prüft mal ob ihr CUxD Timer habt und schaltet die mal im Historian ab. Ev. hilft es. Schaden kann es sicher nicht.

Hallo Ralf,

bei mir taucht gar kein CUxD-Gerät im Historian auf. Oder verstehe ich da gerade etwas falsch?

LG,
Marcel

[Tibin]

@derrapf: Habe mir mal den Beitrag von Mathias in seinem Thread angeschaut, und kann dazu nur sagen, dass bei mir 16 Timer über CuXD laufen und alle Datenpunkte im Historian standardmäßig (hab da nix eingestellt ) aufgezeichnet werden. Und das in einem Zeitraum von über einem Jahr von Okt. 19 bis Dez 20 damals mit der FW 3.51.6
Dann hatte ich mal CuXD aktualisiert, neu gestartet und innerhalb von 10 Tagen 2x Ausfall der IP-Geräte (kurz gesagt)
Da das jetzt schon in unterschiedlichen FW-Versionen und Addon-Versionen mit den gleichen Fehlermeldungen passiert ist, schiebe ich es zumindest für mich nicht mehr darauf. Du hast ja auch selbst geschrieben, dass es bei dir auch ohne Historian passiert ist.
Bei mir persönlich treten diese Fehler seit der 3.47.18 und seit dem ich IP-Geräte habe, auf. Ursache????
Sag mal, hast du eigentlich in deinem messages-Log auch die gleichen Meldungen wie Mutze und blackbasket (und ich)?
Seitdem ich die 3.55.10 installiert habe, ist übrigens jetzt seit 28 Tagen Ruhe.

bei mir taucht gar kein CUxD-Gerät im Historian auf. Oder verstehe ich da gerade etwas falsch?

Du hast bestimmt gar keine CuxD-Timer, oder?
Bei deinem Fehlerlog kommt doch bestimmt vor den Einträgen ....mmd_hmip: not enough space in buffers.... noch irgendwas mit ...transport error... , oder? (nur zum Vergleich)
Damals als ich nach so einigen Abstürzen so lange Uptime hatte, habe ich die FW einfach nochmal drübergebügelt.
Kannst du ja mal mit der jetzigen probieren
Gruß Tino.