Aus den aktuellen Alfred-Daten wurde diese Pivot-Tabelle gefüttert.
Es ist nach der Anzahl an Routern gefiltert, damit die für uns relevantesten Modelle oben stehen.
Es drängt sich auf, dass die 841er ziemlich stark ausgelastet sind im Mittel und mit 15% nur die prozentuale Hälfte an freiem Ram gegenüber allen Modellen im Mittel haben.
Die uptime Werte müssten unterdurchschnittlich sein, da wir vor ein paar Tagen ein autoupdate hatten…
Hi Apo,
nette Tabelle.
Die hohe Load (841er) wird sicherlich durch die FastD Encrytion/Decrytion entstehen.
Was ich aber seltsam finde, ist die geringe uptime der 1043nd Systeme.
Das Gerät läuft eigentlich ohne zu murren durch.
Ich bin mir nicht sicher, ob ihr da vielleicht auf dem Holzweg seid.
Da ich letzte Woche ebenfalls mit einem 841er in Freifunk eingestiegen bin und mich die extrem be-§/($!"%§"$-e Performance ziemlich genervt hat, habe ich mal angefangen das ganze zu debuggen.
Hauptursache für die Load ist alfred. Warum kann ich aktuell noch nicht sagen, weil die debugging Möglichkeiten auf dem System doch sehr bescheiden sind. Aber die aktuelle Indizienlage weißt darauf hin, dass der alfred durch einen page alloc failure total aus dem Ruder läuft und das gesamte System dadurch Amok läuft. Ich „vermute“, dass alfred nach dem ersten page alloc failure am laufenden Band weiter Speicher allocaten will, den er aber nicht sauber zugeteilt bekommt, bis er irgendwann den nächsten page alloc failure wirft. Das setzt das vm-management des Kernels wiederum so sehr unter Druck, dass die load unter die Decke geht. Ursächlich ist wohl, dass alfred einen zu großen zusammenhängen Speicherblock haben will, den das System aber nicht zur Verfügung stellen kann, weil aufgrund des niedrigen Hauptspeichers des 841 der verbleibende Ram ziemlich fragmentiert ist.
Schießt man den alfred hart ab, dann beruhigt sich das System recht schnell wieder auf <1 load und bleibt auch scheinbar da. Ob die Funktionalität beeinträchtigt ist, konnte ich aber noch nicht testen - ich denke ihr könnt die Frage aber auch so beantworten 
Denn was sich mir noch nicht so ganz erschließt, ist wofür man den alfred eigentlich braucht. Das was Google mir ausgespuckt hat, suggeriert, dass er eigentlich „nur“ ein paar Daten einsammelt und die einmal pro Minute an einen zentralen alfred master schickt, der diese Daten wieder ablegt. Wenn dem so ist, dann frage ich mich, warum er soviel Speicher frisst.
Du hast das schon richtig rausgefunden, Alfred trägt nur Statistikdaten zusammen, die dann auf den Karten der Communities dargestellt werden.
Warum der so viel Speicher braucht, kann ich gerade nicht sagen. Aber er ist halt prinzipiell daraus ausgelegt, die Daten der reinen Meshknoten hinter ihm mit weiterzuleiten.
Ziemlich coole Beobachtung!
Den Speicher verbraucht in Wirklichkeit batman-adv. Jeder Prozess, der auf Daten von batman-adv im debugfs zugreift, allokiert dabei unseriös große Speicherblöcke, was bei den kleinen Knoten auch gerne schon mal zu einer resource exhaustion führen kann - weshalb alfred auch gelegentlich dort crasht.
@anon75826926 bemüht sich aber schon seit dem WCW um einen Bugfix gegen batman-adv.
Wir wissen, dass der batman-adv (in beiden derzeit genutzten Codeständen) für Router „mit nur 32MB RAM“ nicht geeignet ist für Layer2-Domains mit >500 Nodes. Allem Anschein nach ist Batman dafür nie designed gewesen.
Die Lösungswege sind bekannt. Einige sind kurzfristig möglich, andere eher mittel- oder gar langfristig.
Zu sagen „kommt davon, wenn man billige Router kauft, geht mit Euren 841ern und Nanostations halt sterben“ ist eine Version, die ich auch schon gehört habe.
Sind die von euch angesprochenen Informationen geheim, oder kann man diese irgendwo nachlesen? Ich bin mir ehrlich gesagt nicht sicher, ob wirklich batman-adv dafür verantwortlich ist, lasse mich aber gerne eines besseren belehren.
Allerdings glaube ich, dass der Ausschluss von 841er HW ziemlich nach hinten losgehen könnte. Denn der nächstbessere Router kostet Stock gleich mal 60€ statt 20€ und würde damit eine deutliche Einstiegshürde darstellen.
Nicht nur das, er ist >90% der installierten Basis.
Und bei den Nanostations von Ubiquity ist das Problem das gleiche.
Oder um es anders zu formulieren: Speicherlecks und Fork-Unfälle mit „mehr Speicher“ zu bekämpfen wäre sehr, sehr peinlich.
Hat mir keine Ruhe gelassen. Ich hab das Gluon auf meinem 841er jetzt etwas getweaked und seit gestern Nacht oopsed er nicht mehr. Mal beobachten, ob das ein permanenter Zustand ist, oder ob es den Exitus nur sehr lange herauszögert.
Gibt es irgendwo eine Anleitung wie man sich ein eigenes Image auf Basis des Bestehenden basteln kann? Würde gerne einige tiefgreifendere Optimierungen durchführen und brauche dafür den Source.
Hier gibt es die Quellen: Freifunk Ruhrgebiet · GitHub
Vermutlich brauchst du diese Konfiguration: https://github.com/ffruhr/site-ffruhr
Dazu natürlich noch Gluon.
Ich würde Dir gern die Illusionen lassen, aber es liegt nicht in Deiner Hand, was für Stürme durch die Broadcast-Domain fegen.
Ich verstehe nicht, was das eine mit dem anderen zu tun haben soll? Bist du sicher, dass du es verstanden hast?
Auch wenn das hier etwas OT ist - mich wundert langsam nicht mehr, dass hier im FFRG die Mühlen so langsam mahlen, wenn jedem potentiellen Unterstützer jeglicher Art scheinbar häufig nur Gegenwind entgegenschlägt.
Sicher nicht, aber leider leidgeplagt mit diesen oder anderen Speicherpanik-Problemen.
(Und ja, man sollte zwischen Ursache und Auslöser unterscheiden. Wobei die Beteiligten durchaus geneigt sind, sich gegenseitig die Schuld in die Schuhe zu schieben.)
Beim zweiten Teil Deines Postings vermute ich mal, dass Du noch nicht bemerkt hast, dass Du Dich mit Deinem Anliegen hier evtl. ins falsche Unterforum verlaufen hast.
Eben das Hin- und Herschieben möchte ich eigentlich mal außen vor lassen und konstruktiv an das Problem gehen. Dass die Ursache die hohe Last in der Domäne Ruhrgebiet ist, steht sicher außer Frage, denn soweit ich das mitbekommen habe, haben andere Domänen keine großen Probleme mit 841er - wobei ich mich da gerne eines besseren belehren lasse.
Aber meiner Meinung nach könnte man die Auswirkungen „relativ“ leicht in den Griff bekommen, wenn man den Memoryfootprint des Gesamtsystems reduzieren würde, um dem alfred die notwendigen Ressourcen zur Verfügung zu stellen. Und dass man das kann, das steht außer Frage. Denn meiner Meinung nach ist das Image noch nicht vollständig in diese Richtung optimiert. Ob das am Ende dann das Problem löst, das kann ich nach aktuellem Stand der Dinge natürlich nicht vorhersagen.
Ist das so? Ich dachte wir sprechen hier von einem technischen Problem in der Domäne Ruhrgebiet und ich bin im Forum Technik/Ruhrgebiet? Hab ich was falsch verstanden? Falls ja, bitte ich um einen Hinweis, wo es besser aufgehoben ist.
Ganz abgesehen davon bin ich sicherlich auch der Meinung, dass diese Unterhaltung nicht mehr zwingend etwas in diesem Thread zu suchen hat. Das möge aber jemand Wissenderes entscheiden.
Technisch möchte ich Dir dringend widersprechen. Du schaust in die falsche Richtung.
Ich werde hier nicht im Detail antworten, da es nichts mit der Technik des Ruhrgebiets zu tun hat und ein reines Openwrt/Gluon-Problem ist und damit hier Offtopic.
(Threads Teilen/Verschieben ist nicht mehr gewünscht von der Mehrheit. Das müsstest Du schon selbst machen.)
