Potrebbe aiutare a salire /proc/sys/vm/page-cluster (predefinito:3).
Dalla documentazione del kernel (sysctl/vm.txt ):
cluster di pagine
page-cluster controlla il numero di pagine fino a cui vengono lette pagine consecutive dallo scambio in un singolo tentativo. Questa è la controparte di swap per il readahead della cache della pagina. La menzionata consecutività non è in termini di indirizzi virtuali/fisici, ma consecutivi su swapspace - ciò significa che sono stati scambiati insieme.
È un valore logaritmico:impostarlo su zero significa "1 pagina", impostarlo su 1 significa "2 pagine", impostarlo su 2 significa "4 pagine", ecc. Zerodisabilita completamente lo swap readahead.
Il valore predefinito è tre (otto pagine alla volta). Potrebbero esserci alcuni piccoli vantaggi nell'impostare questo valore su un valore diverso se il tuo carico di lavoro è ad alta intensità di scambio.
Valori più bassi significano latenze inferiori per errori iniziali, ma allo stesso tempo errori extra e ritardi I/O per errori successivi se fossero stati parte di quelle pagine consecutive che il readahead avrebbe portato.
La documentazione non menziona un limite, quindi forse potresti impostare questo assurdamente alto per fare in modo che tutto lo scambio venga riletto molto presto. E ovviamente riportalo a un valore sano in seguito.
Mi sembra che non puoi magicamente "rendere di nuovo reattivo il sistema". O incorri nella penalità o rileggi le pagine dallo spazio di scambio alla memoria ora o lo incorri in seguito, ma in un modo o nell'altro lo incorri. In effetti, se fai qualcosa come swapoff -a && swapon -a allora potresti sentirti di più dolore piuttosto che meno, perché costringi a copiare alcune pagine nella memoria che altrimenti non sarebbero mai più state necessarie e alla fine rilasciate senza essere lette (pensa:chiudi un'applicazione mentre gran parte del suo heap viene scambiato; quelle pagine possono essere scartato del tutto senza mai essere riletto in memoria).
ma questo cancella le pagine dallo scambio, quindi devono essere riscritte la prossima volta che eseguo lo script.
Bene, praticamente qualsiasi pagina che viene copiata dallo swap nella memoria principale sta per essere comunque modificata, quindi se mai dovesse essere spostata indietro per scambiare di nuovo in futuro, dovrebbe essere riscritta comunque nello 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 -a trucco è buono come qualsiasi cosa tu possa inventarti.
Puoi provare ad aggiungere i programmi che ti interessano di più a un cgroup e regolare lo swappiness in modo che la prossima volta che l'applicazione esegue i programmi che aggiungi abbiano meno probabilità di essere candidati per lo scambio.
Alcune delle loro pagine verranno probabilmente ancora sostituite, ma ciò potrebbe aggirare i problemi di prestazioni. Gran parte di esso è probabilmente solo il comportamento "stop and start" quando molte pagine di un programma sono in swap e il programma deve continuamente mettere in pausa per scambiare le sue pagine nella RAM, ma solo con incrementi di 4k.
In alternativa, puoi 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.