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.
5 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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+) - #12 von Felix im Hinterkopf haben.
3 „Gefällt mir“
In BATMAN 2019.1 gab es auch einen Memory Leak, weswegen unsere Gateways nun alle mit 2019.2 laufen. Mal sehen ob das hilft.
1 „Gefällt mir“
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.
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 „Gefällt mir“