KNX DISCONNECT_REQUEST kurz nach Mitternacht

[Nanosonde]

zum bauen des Kernels habe ich bei einem CentOS 6.5 Minimal habe ich noch folgende Pakete installieren müssen.

Ah, danke! Das hatte ich ganz vergessen zu erwähnen.
Habe das Posting aktualisiert.

[Nanosonde]

Hallo zusammen,

schlechte Nachrichten:
Jetzt hat es bei mir wieder angefangen mit den Problemen um kurz nach Mitternacht.
Das gleiche Problem trotz des aktuellen Mainline Kernel 4.9.11.
---(Das Bauen eines eigenen Kernels kann man sich im übrigen sparen, wenn das "EL Repo" Repository benutzt:
http://elrepo.org/tiki/kernel-ml (mainline) oder auch auch http://elrepo.org/tiki/kernel-lt (long term).
Einfach einbinden und einen passenden Kernel per YUM installieren.)---

Ich habe nun weiter geforscht: Der Swap-Bereich wird nicht genutzt, ABER ich sehe beim RAM folgendes nach ein paar Tagen:

[root@edomi ~]# free -h
             total       used       free     shared    buffers     cached
Mem:          3.8G       1.4G       2.4G       372K       130M       1.0G
-/+ buffers/cache:       292M       3.5G
Swap:         3.0G         0B       3.0G

Der benutzte Speicher steigt immer weiter an. Allerdings offenbar nur bedingt durch den "cached" Teil.
Aktuell sieht es so aus, als würde das Problem immer dann auftreten, wenn der "cached" Teil anwächst.

Führe ich ein "sync; echo 1 > /proc/sys/vm/drop_caches" aus, um den Cache-Inhalt zu verwerfen, sieht die Ausgabe von "free -h" wieder so aus:

[root@edomi ~]# free -h
             total       used       free     shared    buffers     cached
Mem:          3.8G       304M       3.5G       372K       280K        35M
-/+ buffers/cache:       268M       3.5G
Swap:         3.0G         0B       3.0G

Danach habe ich dann wieder ein paar Tage Ruhe.

Hat jemand eine Idee, was das sein könnte?

[Nanosonde]

Seit dem letzten Posting wurde die Kiste nicht neu gestartet. Allerdings wurde einige wenige Male die Projektaktivierung durchgeführt.

Jetzt sieht es wieder so aus:

[root@edomi ~]# free -h
             total       used       free     shared    buffers     cached
Mem:          3.8G       1.4G       2.4G       372K       121M       1.0G
-/+ buffers/cache:       301M       3.5G
Swap:         3.0G         0B       3.0G
[root@edomi ~]#

Ich rechne damit, dass es heute Nacht wieder passiert.

[ggt]

Hallo Nanosonde

Wie sieht es bei "cat /proc/sys/vm/swappiness" aus? Der Wert sollte >10 sein, default ist 60.
Je größer der Wert umso früher wird die swap genutzt.
Temporär kannst du das mit "sysctl vm.swappiness=x" anpassen. Dauerhaft vm.swappiness=x in /etc/sysctl.conf eintragen.

Du kannst die Systemaktivitäten protokollieren. Dafür müsstest du sysstat installieren yum install sysstat
Die protokollierten Daten sollten sich dann im Verzeichnis /var/log/sa/ befinden und werden per default 1 Woche vorgehalten.
Anzeige der Daten z.B. mit sar -r

[DerSeppel]

Hat jemand eine Idee, was das sein könnte?

Ja, normales Systemverhalten. Dafür ist der RAM da. RAM der zum Cachen verwendet wird wird sofort wieder freigegeben wenn eine Applikation ihn benötigt.
Warum sollte das System den ganzen RAM leer halten, wenn man damit das System beschleunigen kann.

Das sieht man wunderbar da dran, dass das System überhaupt keine Not hat den Swap zu verwenden.

Ein ähnlicher Effekt tritt bei mir auch auf. Nur dass bei mir der Cache und die Buffer als leer angezeigt werden. Scheint bei mir aber ein Bug zu sein, da ich das OS dazu zwingen kann den Speicher freizugeben wenn ich versuche ihn zu allokieren. Obwohl er als used angezeigt wird.

Edit: Weiteres hier: http://www.linuxatemyram.com/

[Nanosonde]

Ja, normales Systemverhalten.

Das das Verhalten in Bezug auf die Verwendung des RAMs normal ist, war mir klar.
Allerdings ist mir nicht klar, warum ich die Probleme bei Edomi habe, wenn offenbar diese Bedingung eintritt.
Vielleicht wird ja doch zwischendurch kurz der Swap benutzt und das killt dann die Performance.

Danke ggt!
Werde ich mal testen.

[hapi]

Hi, kurze Solidaritätserklärung. Hatte auch jede Nacht diese Disconnects, seit ich das Backup abgeschaltet habe, nicht mehr. Edomi läuft in einer großzügigen VM auf einem 16-Kern HP Server. Ressourcenprobleme sollte es nicht geben.

[DerSeppel]

Vielleicht wird ja doch zwischendurch kurz der Swap benutzt und das killt dann die Performance.

Eigentlich dürfte der Swap doch die Performance trotzdem nicht so weit runter ziehen.
Aber es ist auf jeden Fall wahrscheinlich, dass beim Anlegen des Backups viele Dateien kopiert werden und daher _nach_ dem Backup der Cache-Anteil im RAM höher ist. Ich würde eher sagen, dass das ein Symptom ist und nicht die Ursache.

Bei mir treten die Disconnects auch sporadisch auf. Auf einem Intel 5i NUC.

[Nanosonde]

Bei mir treten die Disconnects auch sporadisch auf. Auf einem Intel 5i NUC.

Interessant. Bei mir ist es auch ein NUC: NUC5CPYH Celeron N3050 DDR3L

[DerSeppel]

Genau der ist es bei mir. 8GB RAM. Da dürfte eigentlich nichts swappen wenn nur Edomi drauf läuft.

[Nanosonde]

Genau der ist es bei mir. 8GB RAM. Da dürfte eigentlich nichts swappen wenn nur Edomi drauf läuft.

Bei mir sind es nur 4GB. Daran dürfte es dann wohl nicht liegen.
Hattest Du mal einen Memtest laufen lassen?

Wie von ggt vorgeschlagen, habe ich nun sysstat laufen. Mal schauen, ob das mehr Licht ins Dunkel bringt...

Aktuell schaut es so aus:

[root@edomi sa]# free -h
             total       used       free     shared    buffers     cached
Mem:          3.8G       1.9G       1.9G       372K       136M       1.4G
-/+ buffers/cache:       315M       3.5G
Swap:         3.0G         0B       3.0G
[root@edomi sa]# uptime
 14:08:31 up 6 days, 23:27,  1 user,  load average: 0.30, 0.31, 0.21
[root@edomi sa]#

Der Switch (HP1820-24G) sagt auch, dass bisher alle Pakete (TX/RX) ohne Fehler waren.

[gaert]

Ich habe sogar nur 2 GB RAM verbaut - und keinerlei Probleme... RAM steht wie festgenagelt bei ca. 12% (oder waren's 15?) - seit Monaten...

[neci]

Ich reihe mich mal auch als Betroffener ein. Seit ca. 2 Wochen kommen fast täglich um 00:00:39 die Meldungen.
Hardware ist ein NUC5i3RYH mit 8 GB und SSD.

[Marha]

Ich bin nun endlich auch dabei, mich mit dem Thema Edomi zu beschäftigen. Edomi läuft bei mir auf einer eignen Hardware (alter PC, keine VM) und ist mit einem Enertex IP-Router über ein Tunnel mit KNX verbunden. Bei mir treten die gleichen Fehler bezüglich der KNX-Verbindung auf, wie sie Nanosonde oben bereits erwähnt hat, aber über den Tag verteilt zu unbestimmten Zeiten (ca. 5 bis 20 Fehler pro Tag). Um mögliche Performance-Probleme seitens Edomi auszuschließen, habe ich einen zweiten Rechner aufgesetzt, auf dem nur CentOS 6.5 min und Edomi installiert ist. In der edomi.ini habe ich nur KNX aktiviert und die IP-Adresse des Routers eingetragen, die ESF-Datei eingelesen und ein leeres Projekt aktiviert. Die Verbindung zu KNX läuft ebenfalls über ein Tunnel des Routers. Ich erhalte auch hier die gleichen Fehler ca. 5 bis 20 über den Tag verteilt.
Die zweite Hardware habe ich nun mit einer IP-Schnittstelle von eibmarkt mit dem KNX verbunden, nicht mehr über einen Tunnel. Das ganze läuft nun schon fast zwei Tage ohne irgendeinen Fehler. Wo kann das Problem bei den Tunnel-Verbindungen liegen?

[SebastianBaeumler]

Wenn ich richtig informiert bin, ist beim IP Interface auch ein Tunnel im Einsatz um mit dem PC auf den Bus zu kommen.
Dem Interface fehlt nur die Möglichkeit zu routen.

Die hier genannten Probleme treten bei mir auch mit dem MDT IP Router auf.
Bisher habe ich nicht genau hingeschaut weil bei mir alles noch in einer experimentellen Umgebung mit Powerline und Co läuft und ich der Infrastruktur nicht traue.

Im Haus wird dann alles direkt verbunden sein mit eigenem VLAN und Co.
So kann ich dann auch andere etwaige Störquellen ausblenden und ich habe ne schöne MirrorPort Funktion.

Interessant ist, dass das Problem nur mit den IP Routern aufzutreten scheint. Oder hat hier schon jemand das Problem mit einem Interface gehabt?

Gruß,
Sebastian