Fare in modo che Linux legga lo scambio di nuovo in memoria

Il kernel Linux sostituisce la maggior parte delle pagine dalla memoria quando eseguo un'applicazione che utilizza la maggior parte dei 16 GB di memoria fisica. Al termine dell'applicazione, ogni azione (digitazione dei comandi, cambio di aree di lavoro, apertura di una nuova pagina Web, ecc.) Richiede molto tempo per il completamento, poiché le pagine pertinenti devono prima essere lette nuovamente da swap.

C'è un modo per dire al kernel di Linux di copiare le pagine dallo scambio alla memoria fisica senza toccare (e aspettare) manualmente ogni applicazione? Eseguo molte applicazioni quindi l'attesa è sempre dolorosa.

Uso spesso swapoff -a && swapon -aper rendere di nuovo reattivo il sistema, ma questo cancella le pagine dallo scambio, quindi devono essere scritte di nuovo la prossima volta che eseguo lo script.

Esiste un'interfaccia del kernel, forse usando sysfs, per istruire il kernel a leggere tutte le pagine da swap?

Modifica: sto davvero cercando un modo per rendere tutti gli swap scambiati. (Grazie derobert!)

[PS serverfault.com/questions/153946/… e serverfault.com/questions/100448/… sono argomenti correlati ma non affrontano la domanda su come far tornare in memoria il kernel Linux da pagine di swap senza cancellare swap.]

Basato sul programma memdump originariamente trovato qui, ho creato uno script per rileggere selettivamente in memoria le applicazioni specificate. 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

Uso: qualcosa del genere

# ./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] [   <=>    ]
# 

Salta rapidamente sulla memoria non scambiata (gigabyte al secondo) e rallenta quando è necessario lo scambio.

Potrebbe essere d'aiuto /proc/sys/vm/page-cluster(impostazione predefinita: 3).

Dalla documentazione del kernel ( sysctl/vm.txt):

Pagina-cluster

il cluster di pagine controlla il numero di pagine fino a cui le pagine consecutive vengono lette dallo scambio in un solo tentativo. Questa è la controparte dello swap al readahead della cache della pagina. La consecutività menzionata non è in termini di indirizzi virtuali / fisici, ma consecutivi nello spazio di scambio - ciò significa che sono stati scambiati insieme.

È un valore logaritmico: impostandolo su zero significa "1 pagina", impostandolo su 1 significa "2 pagine", impostandolo su 2 significa "4 pagine", ecc. Zero disabilita completamente la lettura dello swap.

Il valore predefinito è tre (otto pagine alla volta). Potrebbero esserci alcuni piccoli vantaggi nell'ottimizzare questo su un valore diverso se il carico di lavoro è ad alta intensità di scambio.

Valori più bassi significano latenze più basse per i guasti iniziali, ma allo stesso tempo guasti aggiuntivi e ritardi I / O per i guasti successivi se fossero stati parte di quelle pagine consecutive che readahead avrebbe portato.

La documentazione non menziona un limite, quindi probabilmente potresti impostare un valore così assurdamente alto da far rileggere tutto lo swap molto presto. E, naturalmente, riportalo in seguito a un valore sano.

Puoi provare ad aggiungere i programmi a cui tieni di più in un cgroup e ad ottimizzare lo swappiness in modo che la prossima volta che l'applicazione esegue i programmi aggiunti abbia meno probabilità di essere candidati per lo scambio.

Alcune delle loro pagine verranno probabilmente scambiate, ma potrebbero aggirare i problemi di prestazioni. Gran parte di esso è probabilmente solo il comportamento "stop and start" quando molte pagine di un programma sono in scambio e il programma deve continuamente mettere in pausa per scambiare le sue pagine in RAM ma solo con incrementi di 4k.

In alternativa, è possibile aggiungere l'applicazione in esecuzione a un cgroup e ottimizzare lo swappiness in modo che l'applicazione sia quella che tende a utilizzare maggiormente il file di scambio. Rallenterà l'applicazione ma risparmierà il resto del sistema.

Mi sembra che non si possa magicamente "rendere di nuovo reattivo il sistema". O incorri nella penalità o rileggi le pagine dallo spazio di scambio nella memoria ora o la incorri in un secondo momento, ma in un modo o nell'altro la incorri. In effetti, se fai qualcosa del genere, swapoff -a && swapon -apotresti provare più dolore piuttosto che meno, perché costringi a copiare alcune pagine in memoria che altrimenti non sarebbero mai state più necessarie e alla fine sono state eliminate senza essere lette (pensa: hai chiuso un'applicazione mentre gran parte del suo mucchio viene sostituito; quelle pagine possono essere scartate del tutto senza mai essere lette in memoria).

ma questo cancella le pagine dallo scambio, quindi devono essere scritte di nuovo la prossima volta che eseguo lo script.

Bene, praticamente ogni pagina che viene copiata indietro dallo swap nella memoria principale sta per essere modificata comunque, quindi se dovesse mai essere spostata indietro per scambiare di nuovo in futuro, dovrebbe comunque essere scritta di nuovo in swap. Tieni presente che lo scambio è principalmente memoria heap, non pagine di sola lettura (che di solito sono supportate da file).

Penso che il tuo swapoff -a && swapon -atrucco sia buono come qualsiasi cosa tu possa inventare.

C'è una bella discussione qui http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that che si riduce alla riduzione della swappiness, con l'idea che per aumentare la reattività percepita del sistema si dovrebbe impedire di scambiare il codice (e questo è ciò che accade). Questa non è in realtà una risposta alla tua domanda, ma ciò potrebbe impedire la visualizzazione del problema (le tue applicazioni non vengono scambiate, solo dati inutilizzati e cache della pagina)