Anpassung der Swappiness

[dfroe]

Hallo,
ich verwende meine mit dem aktuellen Freetz trunk geflashte FritzBox 7270 relativ intensiv, d.h. neben einem ausgewachsenen Asterisk laufen auch ständig mehrere OpenVPN-Tunnel, Sixxs IPv6, RRDstats, und andere Spielereien. Am USB-Port der FritzBox habe ich einen mit ext3 formatierten USB-Stick angeschlossen, auf dem ich zusätzlich zu den rund 60 MB RAM nochmal 64 MB Swap eingerichtet habe; eben für den Fall der Fälle.

Nun beobachte ich jedoch bei mir das Phänomen wenn die FritzBox für 2-3 Tage läuft, dass der Linux-Kernel intensiv RAM-Seiten auslagert, um dadurch den RAM-Cache vergrößern zu können. Teilweise sieht das dann so aus, dass der RAM-Cache auf bis zu 32 MB anwächst, und dafür einige RAM-Seiten auf den Swap geschoben werden. Dieses Verhalten macht in einem PC mit interner Festplatte durchaus Sinn, auf der FritzBox mit Swapfile auf dem USB-Stick bringt dieses Verhalten meine FritzBox jedoch zum Stillstand. Irgendwann steigt die I/O-Last so weit an, dass sich die Box via SSH höchstens noch rebooten lässt. Ich vermute, dass der hohe I/O-Wait Anteil auf den USB-Flaschenhals des Swap-Spaces zurück zu führen ist.

Im Anhang habe ich zwei Screenshots der RRDstats meiner FritzBox angehängt. Darauf ist sehr schön zu erkennen, wie der RAM-Cache permanent vergrößert wird. Dabei wird auch in Kauf genommen, dass der durch Prozesse belegte RAM durch Auslagern verkleinert wird. Irgendwann kommt es durch enormen I/O-Load wegen des Ein-/Auslagerns zu einer Kettenreaktion, dass immer mehr Prozesse auf I/O warten, die Last steigt kontinuierlich an, und irgendwann schlägt ein automatischer Reboot zu, der womöglich durch einen zu spät reagierenden Watchdog-Timer ausgelöst wird.

Ich sehe das Problem darin, dass der Linux-Kernel bzgl. der Swappiness auch auf der FritzBox mit dem Standard-Wert von 60 läuft. Diese Einstellung veranlasst den Kernel dazu, durchaus in größerem Maße RAM-Seiten zu Gunsten des Caches absichtlich auszulagern. Nach meinen Erfahrungen ist für die FritzBox mit USB-Swap dieses Verhalten jedoch etwas zu aggressiv. Ich habe die Swappiness nun manuell auf den Wert 10 gesetzt, so dass der Swap-Space nun im Normalbetrieb komplett unangetastet bleibt, und die FritzBox spürbar stabiler läuft.

Eine kurze Erklärung was es mit dieser Swappiness auf sich hat gibt's z.B. hier:
http://juliusbeckmann.de/blog/linux-speichermanagement-tunen-swappiness.html

Ich habe in meinem Autorun-Script den Wert wie folgt angepasst:

echo 10 > /proc/sys/vm/swappiness

Dieser Aufruf kann auch problemlos vor dem Einbinden irgendwelchen Swaps ausgeführt werden, es schadet auch nichts, die Swappiness anzupassen obwohl gar kein Swap verwendet wird.

Vielleicht sollte man innerhalb des Freetz Entwicklerteams diesen Punkt mal auf die ToDo-Liste setzen, ob man diesen swappiness-Wert nicht vielleicht direkt im swap-initscript über die /proc-Kernelschnittstelle entsprechend korrigiert (oder im Idealfall vielleicht sogar über das Webinterface einstellbar macht). Mit dem Default-Wert von 60 habe zumindest ich jedenfalls schlechte Erfahrung machen müssen.

Gruß
David

 

[Silent-Tears]

Liegt aber denke ich vor allem an deiner intensiven Benutzung der Box mit Dingen, die _eigentlich_ wohl ein wenig zu gross für eben diese sind. Diverse Tunnel, Verbindungen, etc ist schon happig für eine kleine Fritzbox.
Die swappiness einstellen... Mal überlegt einen PAtch gegen den trunk zu produzieren, der diesen Wert einfach in den Einstellungen des swaps der Box hineinzupatchen und diesen hie ranzuhängen? Dazu im init fürs swap einen "echo"-Befehl mit einbauen, der eben dies zur Verfügung stellt.

 

[dfroe]

Sicherlich kann meine Nutzung der FritzBox über die des Durchschnittsusers hinaus gehen, das wage ich nicht zu bezweifeln.
Wobei ich die Box keinesfalls als überlastet bezeichnen würde, denn von den 60 MB RAM sind bei mir auch nur 35-40 MB real durch Prozesse belegt. Somit bleiben noch rund 20 MB für den Cache, was soweit vollkommen in Ordnung geht. Solange eben kein Kernel auf die Idee kommt, unbedingt noch mehr Cache haben zu wollen.

Ich sehe das daher auch eher als "allgemeine Verbesserung", denn für alle anderen Nutzer wäre eine optimierte Swappiness auch zumindest kein Schaden. Der Zugriff auf den USB-Swap dürfte nämlich nie so schnell sein, dass sich ein Auslagern von RAM-Seiten zu Gunsten des Caches jemals lohnen würde.

Der Patch wäre eigentlich ganz simpel, ich bin mit diff & Co. jedoch aus dem Stand heraus nicht top fit. Wenn du schreibenden Zugriff auf das SVN-Repository hast, könntest du vielleicht einfach die Änderung direkt comitten?

Es geht um die Datei, die in der Firmware später unter /mod/etc/init.d/rc.swap landet.

Da müsste die start() Routine wie folgt ergänzt werden (das rote, fett gedruckte muss dazu):

start () {
        echo -n "Starting $DAEMON..."

        if has_swap; then
                echo 'already running.'
                exit 1
        fi

        [B][COLOR="Red"]# tune swappiness
        # to avoid useless swapping over slow usb
        echo 10 > /proc/sys/vm/swappiness[/COLOR][/B]

        ii=0
        # wait for

Mehr ist es für's erste gar nicht.

 

[Silent-Tears]

Ich könnte. Aber du könntest auch den Umgang mit "diff" lernen, ist ziemlich einfach. Files ändern, und per "svn diff > filename.patch" den Patch erzeugen.

 

[sf3978]

[...]
..., ich bin mit diff & Co. jedoch aus dem Stand heraus nicht top fit.
[...]

Du wirst doch noch "find" und "diff -Naur" anwenden können, oder?

--- root/etc/init.d/rc.swap.orig	2010-07-08 00:15:26.000000000 +0200
+++ root/etc/init.d/rc.swap		2010-07-08 00:15:46.000000000 +0200
@@ -17,6 +17,10 @@
 		exit 1
 	fi
 
+	# tune swappiness
+        # to avoid useless swapping over slow usb
+        echo 10 > /proc/sys/vm/swappiness
+
 	ii=0
 	# wait for
 	# - usb device to settle

 

[RalfFriedl]

Gibt es auch Erfahrungen mit anderen Werten?
Die Änderung von 60 auf 10 ist doch recht extrem.

Und was passiert bei Dir an den Stellen, wo die Zacken in den Diagrammen sind?

 

[olistudent]

Ich habe bis jetzt die Erfahrung gemacht, dass die Box relativ spät anfängt auf den Swap auszulagern. Ich würde bei dir fast vermuten, dass irgendwelche Logs unter /var liegen, die mit der Zeit anwachsen?

MfG Olivder

 

[dfroe]

Du wirst doch noch "find" und "diff -Naur" anwenden können, oder

Wenn man was, dass "-Naur" die "gebräuchlichen" Parameter sind - ich kenne das übliche diff-Format landläufig, aber dass man es ausgerechnet mit diesen Parametern erstellt.. nunja.
Der Tipp mit dem "svn diff" war übrigens gut, dass das selbe auch direkt über svn geht wusste ich nicht. Das sieht doch auch gleich viel komfortabler aus.

Und was passiert bei Dir an den Stellen, wo die Zacken in den Diagrammen sind?

Ein (irgendwie per Hardware getriggerter) Reboot, vermutlich durch einen abgelaufenen Watchdog-Timer. Die Box bootet wieder frisch mit leerem Swap, und füllt sich langsam aber kontinuierlich.

Ich würde bei dir fast vermuten, dass irgendwelche Logs unter /var liegen, die mit der Zeit anwachsen?

Volltreffer. Unter /var/logs hatte ich nichts verdächtiges gefunden, aber wenn man sich auch das Verzeichnis /var etwas genauer unter die Lupe nimmt, könnte man wie in meinem Falle fündig werden. Der Übeltäter ist /var/iw.log. Auf einer anderen FritzBox mit der selben Firmware ist diese Datei nach 5 Tagen uptime gerade mal 0,5 MB groß, auf meiner belegt diese nach einem Tag jedoch schon 10 MB. Ich hatte die inotify-Tools installiert, weil ich zu einem späteren Zeitpunkt damit in Zusammenhang mit meinem Asterisk ein paar kleine Scripte testen wollte. Aber dass dabei permanent sämtliche Zugriffe im RAM mitgeloggt werden, das war natürlich ein Schuss ins Knie. Bei "binaries only" bin ich nicht davon ausgegangen, dass da automatisch ein init-Script mit dabei ist. Durchscrollen des Hilfe-Textes hätte natürlich geholfen. Sorry für diesen banalen Anfängerfehler. Die neue Firmware ohne inotify-tools als Schnellschusslösung kompiliert bereits.

Grundsätzlich zum Thema swappiness ist mir z.B. auch auf meiner kleinen NAS-Box (ARM embedded, Linux 2.6.30) mit 512 MB RAM ebenfalls aufgefallen, dass mit einer Swappiness von 60 auch dort hin und wieder gerne ausgelagert wird, um Platz für den Cache zu schaffen. Soo außergewöhnlich scheint dieses Verhalten denke ich nicht zu sein. Ich würde vermuten, dass der Kernel hauptsächlich dann den Cache vergrößern möchte, wenn in regelmäßigen Abständen Daten von einem Massenspeicher gelesen werden. Eine "normale" FritzBox macht dies womöglich äußerst selten, bei mir greift der Asterisk z.B. zum Abspielen von MusicOnHold und diversen Sprachdateien relativ häufig auf den USB-Stick zu. Vielleicht beeinflusst auch das das Swap-Verhalten.

 

[RalfFriedl]

Eine "normale" FritzBox macht dies womöglich äußerst selten

Eine "normale" FritzBox verwendet keinen Swap, weil kein Swap zur Verfügung steht.

 

[dfroe]

Eine "normale" FritzBox verwendet keinen Swap, weil kein Swap zur Verfügung steht.

Da hast du natürlich Recht.
Es war so gemeint, dass sagen wir eine gefreetzte FritzBox ohne Asterisk, auch wenn sie Swap besitzen würde, nur recht zögerlich RAM-Pages auslagern würde, um dadurch RAM für den Cache gewinnen zu können.
Worauf ich hinaus wollte: Wenn regelmäßig Disk-I/Os statt finden (z.B. im Falle eines Asterisks), dann neigt - zumindest bei mir - der Kernel dazu, RAM-Pages zu Gunsten des Caches auszulagern.

 

[RalfFriedl]

Mir ist aufgefallen, daß bei mir der Swap-Bereich sehr selten genutzt wird.

 

[D00mhammer]

sobald bei mir eine anwendung im debian chroot läuft wird swap bereich genutzt - auch wenn die anwendung beendet ist, bleibt die auslagerun bestehen..

 

[Fox.Mulder]

Mit der xx.04.88er Firmware für meine 7270 hatte ich auch mit Swappiness von 60 keine Probleme mit der Auslagerung. Anders ist es jedoch mit der xx.05.21er Firmware. Dabei habe ich das gleiche von dfroe geschilderte Verhalten. Zuerst läuft die Fritzbox recht problemlos. Danach stockt es schon einmal beim Zugriff auf das Webinterface oder auch beim normalen Laden von Webseiten im Webbrowser. Dabei kommt es schon mal vor, dass die Festplatte erst aus dem Ruhezustand aufgeweckt werden muss, und der Internetzugang erst danach wieder möglich ist. SIP Telefonzugänge sind von außen vorübergehend nicht erreichbar. Ab und zu kommt es auch vor, dass die Fritzbox rebootet. Das Verhalten ist alles andere als stabil! Ist natürlich blöd, wenn die Fritzbox RAM Seiten zugunsten von Cache Speicher auslagert und damit wichtige Prozesse verlangsamt und das System destabilisiert.

Ist halt etwas unschön, wenn wichtige RAM Inhalte auf Festplatte ausgelagert werden und dann auch noch der Motor abgeschaltet wird.

Gibt es außer der Verringerung des Swappiness Wertes noch weitere Eingriffsmöglichkeiten, um dieses nicht gewünschte Verhalten zu verbessern und die Box zu stabilisieren?

 

[RalfFriedl]

Ist halt etwas unschön, wenn wichtige RAM Inhalte auf Festplatte ausgelagert werden und dann auch noch der Motor abgeschaltet wird.

Es gibt dafür zwei Ansatzpunkte:
Kein Swap auf eine Festplatte einrichten.
Eine Festplatte, auf der Swap ist, nicht ausschalten.

Was schwebt Dir den vor? Einen Swapbereich einrichten, aber die Box dazu bringen, diesen nicht zu nutzen?
Wenn ein Speicherblock länger nicht mehr genutzt wurde, ist er ein Kandidat für Swap. Das kann durchaus das Programm für Webzugriff oder Telefon sein, wenn dieses schon länger nicht mehr genutzt wurde.

 

[Fox.Mulder]

Mit Swappiness=10 habe ich ebenso das Problem, dass der Internetzugang vorübergehend nicht geht, obwohl fast nichts ausgelagert zu sein scheint.

Bei Verwendung der gleichen Programme auf der FritzBox funktioniert diese mit der Version xx.04.88 problemlos und mit der xx.05.21 ist sie absolut instabil. Bei der xx.04.88 wird auch ausgelagert! Trotzdem funktioniert die Box incl. dem vorübergehenden Herunterfahren des Festplattenmotors. Irgendwie scheinen die Programme bei der xx.05.21 mehr CPU Last zu verursachen. Bisher konnte ich die Firmware mit dem neuen Kernel nicht dauerhaft einsetzen und war gezwungen, immer wieder auf die xx.04.88 zurückzuflashen.

 

[RalfFriedl]

Vielleicht hat die neue Firmware einen Kernel, der eher etwa auslagert. Mit dem alten 2.6.13 habe ich es fast nicht geschafft, überhaupt etwas auszulagern.
Vielleicht brauchen die Programme in der neuen Firmware mehr Speicher, so dass eher ausgelagert wird.
Du könntest zum Auslagern einen USB-Stick verwenden, da stellt sich nicht die Problematik mit dem Abschalten von Festplatten.

 

[Suchiman]

Jo nur, dass USB-Stick wegen der Flash beschaffenheit da schnell von sterben kann, leider.
Hast du auch Swappines 0 probiert?

swappiness=0 tells the kernel to avoid swapping processes out of physical memory for as long as possible

 

[olistudent]

Wenn die Box hin und wieder rebootet, dann solltest du auf die Suche nach dem Schuldigen gehen. Hört sich für mich so an als gäbe es da ein Speicherleck...

Gruß
Oliver

 

[RalfFriedl]

Jo nur, dass USB-Stick wegen der Flash beschaffenheit da schnell von sterben kann

Die Zeitschrift c't hat mal versucht, gezielt solange zu schreiben, bis die Sticks kaputt sind, sie haben es nicht in überschaubarer Zeit geschafft.
Das schlimmste, was passieren kann ist, dass mal gelegentlich einen USB-Stick ersetzen muss. Und für Swap tut es 1GB oder noch weniger, also die kleinsten, die man überhaupt bekommen kann, auch alte, die so klein sind, dass keiner mehr sie verwenden will.

 

[Fox.Mulder]

Einen Stick werde ich bei Gelegenheit mal probieren. Ebenso werde ich mit einer minimalen Freetz-Konfiguration probieren, ob sich die Stabilität damit verbessert. Nach einem Speicherleck sieht es derzeit nicht aus, da der Speicher incl. Swap ja nicht übermäßig belastet wird. Sieht eher nach übermäßiger CPU Last aus oder, dass eine wichtige Funktion nicht mit der entsprechenden Wiederholrate ausgeführt werden kann, weil eine andere Funktion in der neuen Kernel Umgebung zu viel Last erzeugt oder irgenetwas blockiert wird.

Habe irgendwo gelesen, dass bei Verwendung (und Aktivierung) eines UMTS Sticks für GSM/UMTS Telefonie nur noch ein recht geringer Datendurchsatz zu USB Speichern erreicht wird. Das könnte für das Auslagern wieder ein zusätzliches Problem erzeugen. Im Moment verwende ich aber noch keinen UMTS Stick für die Telefonie.