Kernel 4.19 (buster, stretch-backports) leakt memory, noch nicht upgraden

In der v4.19er Serie befindet sich derzeit noch ein Memory-Leak, was Freifunk-Gateways betrifft.

Ein Update auf Debian Buster und seinen v4.19 Kernel ist daher im Moment nicht anzuraten.

Details: netdev - Memory leaks in IPv6 ndisc on v4.19.56

5 Likes

Das erklärt warum unsere GWs mit 4.19er Kernel alle 14 Tage hops gehen …

Danke fĂĽr die Warnung. Leider kann ich wegen VRF Support nicht downgraden :(.

1 Like

planned maintenace reboot 1* wöchentlich? :-/

das wäre eine Strategie wenn das „einmal wöchentlich rebooten“ sich auf „hohe Uptime“ beschränken würde. Ich vermute(!) jedoch, dass es einfach zufällig eine Condition gibt, die das Problem in Lauf setzt (irgendwann binnen der angenommenen „Woche“) und dann einmal ausgelöst binnen Stunden/Minuten zum oom-panic/reboot führt.

1 Like

Alarm in Grafana und LibreNMS für SWAP und RAM … und wenn es passiert hat man meistens so ne Stunde Zeit zu resetten ohne Impact.

Und einfach the good old „Throwing more hardware at the problem“. Nachdem wir über den Luxus von viel RAM auf unseren KVM Hosts verfügen haben wir einfach mal 6GB pro GW zugewiesen und schauen jetzt mal … Davor waren es 4GB und da hielt es etwa 2 Wochen.

AuĂźerdem haben wir unsere Gateway Dashboards deutlich aufgebohrt.
https://stats.ffmuc.net/d/lsTdmFIZz/gateway-extended-system-dashboard

1 Like

Unter Proxmox 5.4-3 sehe ich sporadisch seit dem Upgrade meiner virtuellen Maschinen auf Buster:

rcu_sched self-detected stall on cpu

Ich warte dann mal mit dem Upgrade unserer Gateways noch ein wenig.

Proxmox 6 hat mit dem gerade frischen Release hat ja jetzt shcon den Sprung auf einen 5er-Kernel gewagt. Da der in dieversen Arch-Installationen auch klaglos im Freifunk-Kontext seinen Dienst verrichtet:

Ist ein 5er-Kernel fĂĽr hier vielleicht einen Test wert?

Unsere Gateways laufen auf Fedora 30 mit aktuell Kernel 5.1.17 extrem stabil.

[felix@gw1 ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:           1990         442         178           0        1370        1364
Swap:          2119          35        2084

[felix@gw1 ~]$ uptime
21:24:30 up 13 days, 17:11,  1 user,  load average: 0.01, 0.02, 0.00

Natürlich sollte man dabei aktuell noch Bug in netfilter_conntrack stört Tunneldigger-Betrieb (Kernel 5.0.20+ und 5.1.6+) im Hinterkopf haben.

3 Likes

In BATMAN 2019.1 gab es auch einen Memory Leak, weswegen unsere Gateways nun alle mit 2019.2 laufen. Mal sehen ob das hilft.

https://www.open-mesh.org/issues/378

1 Like

Hat nicht geholfen … :/.

hi

Ein Freifunkkollege hat bei uns was gefunden. Es hat irgendwas mit systemd & cgroups zu tun. Bei uns hat das checkmk (aber nur wenn man die Ausgabe cryptet) den Effekt ausgelöst das nach einigen Tagen der RAM voll war. Er konnte es sauber reproduzieren (jeder Aufruf des checkmk’s hat den Speicher ein bisschen weiter gefüllt). Aufgetreten ist es nach Buster Upgrade. Speicher wurde im Kernel nicht mehr freigegeben, ob cgroups, Kernel oder systemd Schuld ist, ist bisher unklar. Aber in dieser Kombination liegt der Hund hier begraben

Eventuell mal cgroups ausschalten (falls das geht) und schauen ob es dann verschwindet. Dann habt ihr wohl das gleiche Problem. Falls euch das hilft und ihr mehr Infos braucht frag ich gerne nach, wie ihr vermutlich merkt hab ich mich selbst nicht mit beschäftigt und gebe nur hörensagen weiter (ich weiß nicht mal genau was cgroups ist ;))

GruĂź

Christian

Ich habe heute alle unsere Gateways auf Kernel 5.2.6 geupdated.

@awlnx und, laufen die besser?

Jup, 5.2.6 macht keinerlei Probleme und läuft einfach. Wir haben jetzt rebooted wegen mehr CPUs in den VMs aber keinerlei Memory Leak mehr.

gibt’s konkrete commits, die da etwas gelöst haben, deren backport nach 4.19 und debian man abwarten muss?

Leider keine Ahnung, ich habe nur einfach auf den neuesten Kernel geupdated und gehofft dass es was löst ;). Nachdem hier Berichte waren, dass es unter Fedora 30 mit Kernel 5.1.7 keine Probleme gibt.

1 Like