Linux-Lesezugriff zurück in den Arbeitsspeicher übertragen

Der Linux-Kernel tauscht die meisten Seiten aus dem Speicher aus, wenn ich eine Anwendung ausführe, die den größten Teil des physischen Speichers von 16 GB verwendet. Nach Abschluss der Anwendung dauert jede Aktion (Eingeben von Befehlen, Wechseln von Arbeitsbereichen, Öffnen einer neuen Webseite usw.) sehr lange, da die relevanten Seiten erst vom Swap wieder eingelesen werden müssen.

Gibt es eine Möglichkeit, den Linux-Kernel anzuweisen, Seiten aus dem Auslagerungsspeicher zurück in den physischen Speicher zu kopieren, ohne jede Anwendung manuell zu berühren (und auf sie zu warten)? Ich führe viele Anwendungen aus, so dass das Warten immer schmerzhaft ist.

Ich verwende oft swapoff -a && swapon -a, um das System wieder reaktionsfähig zu machen, aber dies löscht die Seiten aus dem Swap, so dass sie beim nächsten Ausführen des Skripts erneut geschrieben werden müssen.

Gibt es eine Kernel-Schnittstelle, die möglicherweise sysfs verwendet, um den Kernel anzuweisen, alle Seiten von Swap zu lesen?

Edit: Ich suche in der Tat einen Weg, um alle Swap Swap-fähig zu machen. (Danke derobert!)

[PS serverfault.com/questions/153946/… und serverfault.com/questions/100448/… sind verwandte Themen, beschäftigen sich jedoch nicht mit der Frage, wie der Linux-Kernel Seiten aus dem Swap zurück in den Speicher kopieren kann, ohne den Swap zu löschen.]

Basierend auf dem Memdump-Programm, das ursprünglich hier gefunden wurde , habe ich ein Skript erstellt, um bestimmte Anwendungen selektiv zurück in den Speicher zu lesen. remember:

#!/bin/bash
declare -A Q
for i in "$@"; do
    E=$(readlink /proc/$i/exe);
    if [ -z "$E" ]; then.
        #echo skipped $i;.
        continue;.
    fi
    if echo $E | grep -qF memdump; then.
        #echo skipped $i >&2;.
        continue;.
    fi
    if [ -n "${Q[${E}]}" ]; then.
        #echo already $i >&2;.
        continue;.
    fi
    echo "$i $E" >&2
    memdump $i 2> /dev/null
    Q[$E]=$i
done | pv -c -i 2 > /dev/null

Verbrauch: so etwas wie

# ./remember $(< /mnt/cgroup/tasks )
1 /sbin/init
882 /bin/bash
1301 /usr/bin/hexchat
...
2.21GiB 0:00:02 [ 1.1GiB/s] [  <=>     ]
...
6838 /sbin/agetty
11.6GiB 0:00:10 [1.16GiB/s] [      <=> ]
...
23.7GiB 0:00:38 [ 637MiB/s] [   <=>    ]
# 

Es überspringt schnell nicht ausgelagerten Speicher (Gigabyte pro Sekunde) und verlangsamt sich, wenn ein Auslagerungsvorgang erforderlich ist.

Es könnte helfen, aufzusteigen /proc/sys/vm/page-cluster(Standard: 3).

Aus der Kerneldokumentation ( sysctl/vm.txt):

Seiten-Cluster

Der Seitencluster steuert die Anzahl der Seiten, bis zu der aufeinanderfolgende Seiten in einem einzigen Versuch vom Auslagerungsvorgang eingelesen werden. Dies ist das Swap-Gegenstück zum Page-Cache-Readahead. Die erwähnte Konsekutivität bezieht sich nicht auf virtuelle / physische Adressen, sondern auf aufeinanderfolgende Swap-Space-Adressen - das heißt, sie wurden gemeinsam ausgetauscht.

Es ist ein logarithmischer Wert - wenn Sie ihn auf Null setzen, bedeutet dies "1 Seite", wenn Sie ihn auf 1 setzen, bedeutet dies "2 Seiten", wenn Sie ihn auf 2 bedeuten, bedeutet dies "4 Seiten" usw. Null deaktiviert Swap Readahead vollständig.

Der Standardwert ist drei (jeweils acht Seiten). Es kann einige kleine Vorteile haben, dies auf einen anderen Wert abzustimmen, wenn Ihre Arbeitsauslastung sehr umfangreich ist.

Niedrigere Werte bedeuten geringere Latenzen für anfängliche Fehler, aber gleichzeitig zusätzliche Fehler und E / A-Verzögerungen für nachfolgende Fehler, wenn sie Teil dieser aufeinanderfolgenden Seiten gewesen wären, die zuvor gelesen wurden.

In der Dokumentation wird kein Limit erwähnt, daher könnten Sie dieses absurd hoch setzen, damit der gesamte Swap sehr bald wieder eingelesen wird. Und natürlich danach wieder auf einen vernünftigen Wert einstellen.

Sie können versuchen, die Programme, die Sie am meisten interessieren , einer C-Gruppe hinzuzufügen und swappiness so zu optimieren , dass es weniger wahrscheinlich ist, dass die Programme, die Sie hinzufügen, beim nächsten Ausführen der Anwendung als Kandidaten für den Austausch in Frage kommen.

Einige ihrer Seiten werden wahrscheinlich noch ausgetauscht, aber es kann zu Problemen mit der Leistung kommen. Ein großer Teil davon ist wahrscheinlich nur das "Stop and Start" -Verhalten, wenn viele Seiten eines Programms ausgetauscht werden und das Programm ständig pausieren muss, um seine Seiten in RAM zu tauschen, jedoch nur in 4-KB-Schritten.

Alternativ können Sie die ausgeführte Anwendung einer cgroup hinzufügen und swappiness so einstellen, dass die Anwendung die am häufigsten verwendete Auslagerungsdatei ist. Die Anwendung wird verlangsamt, aber der Rest des Systems wird geschont.

Mir scheint, dass Sie das System nicht auf magische Weise "wieder reaktionsfähig machen" können. Sie müssen entweder die Strafe zahlen oder Seiten aus dem Auslagerungsspeicher in den Speicher zurücklesen, oder Sie müssen sie später bezahlen, aber auf die eine oder andere Weise müssen Sie sie bezahlen. In der Tat, wenn Sie so etwas tun, swapoff -a && swapon -averspüren Sie möglicherweise mehr Schmerzen als weniger, weil Sie erzwingen, dass einige Seiten zurück in den Speicher kopiert werden, die andernfalls nie wieder benötigt worden wären und schließlich gelöscht würden, ohne gelesen zu werden (denken Sie: Sie beenden eine Anwendung, während ein Großteil des Heaps ist ausgelagert, diese Seiten können gänzlich verworfen werden, ohne jemals in den Speicher zurückgelesen zu werden.

Dadurch werden die Seiten jedoch vom Auslagerungsmodus befreit, sodass sie beim nächsten Ausführen des Skripts erneut geschrieben werden müssen.

Nun, so ziemlich jede Seite, die vom Auslagern in den Hauptspeicher zurückkopiert wird, wird sowieso geändert. Wenn sie also in Zukunft zum erneuten Auslagern zurückgezogen werden müsste, müsste sie sowieso neu im Auslagerungsmodus geschrieben werden. Denken Sie daran, dass Swap hauptsächlich aus Heapspeicher und nicht aus schreibgeschützten Seiten besteht (die normalerweise dateibasiert sind).

Ich denke, Ihr swapoff -a && swapon -aTrick ist so gut wie alles, was Sie sich vorstellen können.

Es gibt eine sehr nette Diskussion hier http://rudd-o.com/de/linux-und-freie-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that Dies läuft darauf hinaus, die Reaktionsfähigkeit des Systems zu verringern und das Auslagern des Codes zu verhindern (und genau das passiert). Dies ist keine wirkliche Antwort auf Ihre Frage, aber dies kann das Auftreten des Problems verhindern (Ihre Anwendungen werden einfach nicht ausgetauscht, nur nicht verwendete Daten und Seiten-Cache).