Erhöhte CPU Load seit dem 19.05.2022

Moin zusammen,

ich betreibe einen Knoten auf Basis eines ALIX Boards. Ich überwache kontinuierlich Parameter wie angemeldete Nutzer, Uptime und eben auch die Systemlast. Diese ist wohl seit dem letzten Update stark gestiegen:

Die Systemlast ist live einzusehen unter: http://worms-wiesoppenheim-alix01.freifunk.duenndns.org/cgi-bin/status

Jetzt die Frage: Ist mit der Firmware 1.6.4-20220505 irgendwas besonders rechenintensives dazugekommen oder warum ist die so stark angestiegen? Mehr Nutzer sind nicht der Grund, da ich hier ziemlich ab vom Schuss bin, das kann es also nicht sein.

Wäre für jegliche Tipps dankbar.

Gruß
Simon

Hab jetzt gerade mal ins top geschaut und folgendes entdeckt:

Für mich sieht das nicht aus als ob das seit dem letzten Update so wäre, das kam später:

Quelle: Grafana

So direkt habe ich aber auch keine Idee. Könnte alles möglich sein. Hast du mal per htop (muss via opkg update; opkg install htop installiert werden) geschaut ob dir da etwas auffällt?

systemd klingt komisch, das wäre mir für OpenWRT neu. ;)

Die anderen Prozesse kommen mir auch erstmal unbekannt vor.

Hab was dazu gefunden: Hohe Load mit gluon testing (1.3~20181118) - Mehrfachaufrufe von dhcpv6.script br-client ra-updated - #3 von dust - Technik - Forum (darmstadt.freifunk.net)

EDIT: Hier gibt’s nen Workaround, sei aber nicht rfc konform. Trotzdem ausprobieren?

Das ist ja aber uralt und der Workarround ist doch sogar seit Gluon 2018.2 (76f5919) mit drin. Also auch bei uns schon längst.

Okay, also ich habe jetzt nochmal nachgeschaut. Das tritt ja seit dem 19.05.2022 auf. Das ist der Tag seit dem wir begonnen haben drei unterschiedliche globale /64 IPv6 Präfixe im Client Netz announcen.


Etwas Hintergrund:

Wir haben aktuell drei dedizierte Server auf denen die Gateways als VM laufen. Jeder dieser drei Server hat ein /56. Der Traffic muss aber halt immer über den richtigen Server in Richtung Hoster gehen. Das schaffen wir per VLAN zwischen den Kisten und etwas Policy Routing.
Um nun weniger Quertraffic zwischen den Kisten zu haben annoucen alle Gateways alle drei Präfixe.
Damit Clients und Knoten nun aber das richtige verwenden haben die falschen valid lifetime 0 und preferred lifetime 0. Damit werden die falschen automatisch immer als depecated markiert und Nodes können auf diesen zwar noch Traffic empfangen, die Adressen werden aber nicht mehr als source für neuen Traffic verwendet.

Damit nun die Clients an einem Knoten nicht Router Advertisements von allen Gateways bekommen gibt es das Paket gluon-radv-filterd. Dieses läuft auf den Knoten, definiert den jeweils besten IPv6 Router und lässt anschließend nur die RAs von diesem zu den Clients durch.


Ich habe es jetzt nicht genau überprüft, aber ich würde es mal als wahrscheinlich einstufen das die erhöhte Anzahl der Präfixe / der RAs die Ursache ist. Leider sehe ich aktuell aber auch keine gute Möglichkeit das zu ändern.
Zuvor hatten wir halt immer gleiche /64 auf allen Gateways. Das führte jedoch dazu das sämtlicher IPv6 Traffic immer erst zu dem Server geroutet werden musste wo der Hoster das /56 (in welchem das /64 drin ist) zugewiesen hat. Das ist auch nicht gerade schick.

Die Lösung wäre wohl (wie auch für andere Probleme im ganzen IPv6 Kontext) sich ein IPv6 PI oder PA Präfix zu besorgen und nur noch dieses zu verwenden.
Das kann dann aber halt auch auf keinem unserer Server direkt ins Internet und muss (sofern wir die Gateways nicht komplett umziehen) immer irgendwohin getunnelt werden.
Hetzner (unser Hoster) bietet meines Wissens halt leider kein (für uns bezahlbares) Angebot womit wir entweder eins von deren Präfixen dynamisch zwischen allen unsereren Systemen verwenden können oder über sie unser eigenes Präfix announcen können.

Ok, soweit verstanden. Aber wie wäre es denn Mal testweise ein gluon Image mit ubus Support zu bauen? So wie es im GitHub issue gehintet wurde. Gerne stelle ich dafür nötigenfalls ein baugleiches zweites ALIX bereit.

Bist du noch derjenige, der das tut?

Für mich liest sich das so als ob da (wenigstens damals) noch Code für fehlte. Dementsprechend ist es wohl eher nicht damit getan eben mal eine neue Firmware zu bauen. Du kannst dir das sehr gerne anschauen, aber aktuell fehlt mir die Zeit die Sinnhaftigkeit näher zu evaluieren.

Ich hoffe eigentlich das wir irgendwann von den multiplen Präfixen wegkommen.