Zusammenhang Clients und Load/Load allgemein

Technik
1

Frage zu Neue Rheinufer Map & Merging Probleme gelöst:

Ich habe mich da nun etwas durchgeklickt. Die Stats sind sehr gut gelungen, danke dafür. Hoffentlich kommt das bald auch in anderen Domänen!

Was mir aufgefallen ist: Die Client-Anzahl und der Load scheinen in keiner direkten Relation zueinander zu stehen. Oder täuscht mich da mein Auge?
Zudem sind auch Knoten (fast) ohne Clients teilweise sehr stark ausgelastet.

Gibt es dafür eine schlüssige Erklärung für Nicht-Techniker wie mich? :smiley:

Vielen Danke und viele Grüße

2

Ich würde da einfach mal vermuten, dass es daran liegt, dass die Load eher mit dem Datendurchsatz als mit den verbundenen Clients zusammenhängt, da ja die Daten alle verschlüsselt werden müssen. Wenn viele Clients verbunden sind aber nicht mit dem Internet kommunizieren verursacht das dann evtl weniger Last, als wenn nur ein Client verbunden ist aber gerade so schnell er kann Daten übertragen möchte.

3

Tja…das mit der Load.

Stell dir eine unendlich breite Strasse mit einer Engstelle (dein System bestehend aus CPU, RAM etc…) vor.

Wenn weit und breit kein Auto zu sehen ist, kannst du ungebremst durchrauschen…das wäre eine Load von 0.

Wenn jetzt einigermaßen Verkehr ist, aber alles zügig rollt und niemand warten (anhalten) muß, aber trotzdem jeder einen Voraus-Fahrenden hat, ist das ein Load von 1

Wenn in der Engstelle Platz für 3 Fahrzeuge ist, und gleichzeitig 3 Fahrzeuge warten müssen, hast du eine Load von 2 usw…

Wie eng die Stelle ist, hängt von vielen Faktoren, u.A. der CPU-Architektur, Speicher-Anbindung, -Grösse, -Ausstattung etc. ab

Viele Prozesse sind viele Autos, und je langsamer ein Taskwechsel oder Kontext-Switch ausfällt, umso grösser muß der Sicherheitsabstand werden. (hängt von der CPU-Architektur ab)

So ganz einfach lässt sich der verflixte Load-Wert einfach nicht erklären :wink:

Die meisten Admins werden ab einem dauerhaften Load von 0,7 nervös, weil das ein sicheres Indiz dafür ist, daß ein grösserer Server fällig wird, oder irgend etwas vor sich geht, von dem sie (noch) nichts wissen :wink:

Kurzzeitige Peaks sind nervig, aber nichts Beunruhingendes :smiley:

4

Ja, genau. Ich kann auch eine hohe Load haben, obwohl die CPU fast nichts macht, da sie die ganze Zeit auf IO wartet. Gute Analysetools für so einen Fall wären iostst oder (gefällt mir besser) dstat. Einen Überblick über die Situation kann man sich z.B. so schnell verschaffen:

dstat -c --top-cpu -d --top-bio --top-latency --nocolor
5

Load habe ich zumindest im Ansatz schon verstanden. Allerdings weiß ich wirklich nicht wie es zu manchen Werten kommen kann. Da gibt es freistehende Knoten ohne Clients, die zwischendurch aus dem nichts einen Load von 3,5 haben.
Berechnen wir verteilt im Netz PI neu? Oder langweilt sich der Knoten und macht deshalb irgendwas? :smiley:

6

@JoBu Der Load-Wert eines Systems ergibt sich nicht allein aus der CPU-Auslastung. Auch Disk- und Network-I/O fließen hier mitunter ein. Auch Systeme mit einer Load von 50 und mehr können durchaus noch „responsive“ reagieren. Pi zu berechnen, muss also nicht der Grund sein. :wink:

Bzgl. deiner Beobachtung/Analyse ergibt sich dadurch: You are holding it wrong! :wink: Was Du nachweisen willst (eine Korellation der Load eines Knotens zur Clientzahl am Knoten) wird dir nur an einem Knoten in Isolation gelingen können, vermute ich. Dein Gegenspieler sind in deinem „Versuchsaufbau“ alle anderen Knoten und Clients im Netz, die die Broadcast-Domain „mit Leben füllen“, genauer Mgmt-Netzwerkdaten (ARP, NS, etc.) durch’s Netzwerk fluten, die an jedem Knoten ankommen. Durch die dadurch entstehenden Pakete (die dein Knoten nicht nur über den VPN-Tunnel empfängt, sondern auch über das WiFi-Mesh weiterleiten und über das Client-WLAN rauspusten muss) wird weitere Last erzeugt. Dass das dann nicht mit der Clientzahl am Knoten selbst korreliert ist klar, Du kannst i.A. aber beobachten, dass die Netzlast mit der Zahl der Clients im Netz steigt und fällt. Einfachster Weg das nachzuvollziehen (wenn Du nicht an euren Gateways spielen darfst), wäre es mit tcpdump mal nachts (= wenige Clients) ein PCAP mitzuschneiden und das gleiche dann nochmal tagsüber (= viele Clients) zu tun und anschließend die Größe der PCAPs zu vergleichen. Die Hamburger haben dafür aber auch schon fertige Grafiken von ihren Gateways. :wink:

1 „Gefällt mir“
7

Vermutlich handelt es sich um Mesh-VPN-Nodes.
Oder um Nodes die (ggf. auch ohne VPNMesh, aber mit MeshOnWan) in einem Netz hängen, in dem viel IPv6-RA unterwegs sind und die daher das OpenWRT ins Taumeln bringen.

Nein, die updateten simultan mit mehreren parallel laufenden Scripten ihre IPv6-Neighbourtabellen und rudern gegen Speicherlecks und Tabellenüberläufe.
Ich tippe darauf, dass >90% der kernelpanics, Speicherfehler, reboots und crashes bei den 32MB-RAM-Geräten zu Lasten von
https://dev.openwrt.org/browser/trunk/package/network/config/netifd/files/lib/netifd/dhcp.script
gehen.
Natürlich ist das nicht primär die Ursache, aber der massiv parallele Aufruf dieses Script (>5 simultane Instanzen) sind „über Stunden und Tage“ problematisch.
(Und das ist leider bei Nutzung von ULAs und/oder IPv6 auf dem WAN-Port leider häufig)

Entschärfen ließe sich dass, wenn es eine gütige Seele gäbe, die das Script auf Queuing umstellen würde.
Also script → Queue-Adder und dazu einen Worker-Thread, der ggf. sogar prüft, ob er überhaupt was ändern muss bevor er wild in den Tabellen herumschreibt.

3 „Gefällt mir“
8

Da hat wohl schon mal jemand genauer hingesehen. :smile: Guter Hinweis darauf, dass durch den Mgmt-Traffic im Netz die Knoten auch einiges zu tun bekommen, ja. :+1:

9

Die Schwierigkeit ist kein Glon-Problem, sondern eines von OpenWRT und muss sinnvollerweise „upstream“ repariert werden.
Unter normalen Umständen ist das auch kein Problem und daher drückt bei den durchschnittlichen OpenWRT-Usern dort kein Schuhn.
Nur wir FreifunkerInnen führen die kleinen Plasterouter mit den riesigen Kollisionsdomains (und den dazugehörigen Neighbourtables) bis ans Limit und darüber hinaus.
Wer würde sonst ein unsegmentiertes LAN bauen mit mehr als 500 Switches und mehr als 1000 client-Rechnern. (Und sich dann wundern, das 15€-Switches da nicht mehr mitkommen)

3 „Gefällt mir“