Rendre la lecture de Linux en mémoire

Le noyau Linux échange la plupart des pages de la mémoire lorsque j'exécute une application qui utilise la plupart des 16 Go de mémoire physique. Une fois l'application terminée, chaque action (saisie de commandes, changement d'espace de travail, ouverture d'une nouvelle page Web, etc.) prend beaucoup de temps car les pages pertinentes doivent d'abord être relues à partir du swap.

Existe-t-il un moyen de dire au noyau Linux de copier les pages du swap dans la mémoire physique sans toucher (et attendre) manuellement chaque application? Je lance beaucoup d'applications, donc l'attente est toujours pénible.

J'utilise souvent swapoff -a && swapon -apour rendre le système réactif, mais cela efface les pages du swap, elles doivent donc être réécrites la prochaine fois que j'exécute le script.

Existe-t-il une interface du noyau, peut-être en utilisant sysfs, pour demander au noyau de lire toutes les pages du swap?

Edit: je cherche en effet un moyen de faire tout swap swapcached. (Merci derobert!)

[PS serverfault.com/questions/153946/… et serverfault.com/questions/100448/… sont des sujets connexes mais n'abordent pas la question de savoir comment obtenir le noyau Linux pour copier des pages de swap dans la mémoire sans effacer swap.]

Basé sur le programme memdump trouvé à l'origine ici, j'ai créé un script pour lire sélectivement les applications spécifiées en mémoire. 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

Utilisation: quelque chose comme

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

Il saute rapidement la mémoire non permutée (gigaoctets par seconde) et ralentit lorsque la permutation est nécessaire.

Cela peut aider à monter /proc/sys/vm/page-cluster(par défaut: 3).

Depuis la documentation du noyau ( sysctl/vm.txt):

groupe de pages

page-cluster contrôle le nombre de pages jusqu'à lesquelles des pages consécutives sont lues depuis le swap en une seule tentative. Il s'agit de la contrepartie de swap à la lecture anticipée du cache de page. La consécutivité mentionnée n'est pas en termes d'adresses virtuelles / physiques, mais consécutives sur l'espace d'échange - cela signifie qu'elles ont été échangées ensemble.

C'est une valeur logarithmique - la mettre à zéro signifie "1 page", la mettre à 1 signifie "2 pages", la mettre à 2 signifie "4 pages", etc. Zéro désactive complètement la lecture anticipée du swap.

La valeur par défaut est trois (huit pages à la fois). Il peut y avoir quelques petits avantages à régler cette valeur sur une valeur différente si votre charge de travail est gourmande en échanges.

Des valeurs plus faibles signifient des latences plus faibles pour les défauts initiaux, mais en même temps des défauts supplémentaires et des retards d'E / S pour les défauts suivants s'ils auraient fait partie de ces pages consécutives que la lecture anticipée aurait apportées.

La documentation ne mentionne pas de limite, donc vous pourriez peut-être fixer ce niveau absurdement haut pour que tout le swap soit relu très bientôt. Et bien sûr, revenez à une valeur saine par la suite.

Vous pouvez essayer d'ajouter les programmes qui vous intéressent le plus à un groupe de contrôle et de régler la permutation afin que la prochaine fois que l'application s'exécute, les programmes que vous ajoutez sont moins susceptibles d'être candidats à la permutation.

Certaines de leurs pages seront probablement encore échangées, mais cela peut contourner vos problèmes de performances. Une grande partie de celui-ci est probablement juste le comportement "stop and start" quand beaucoup de pages d'un programme sont en swap et que le programme doit continuellement faire une pause pour échanger ses pages en RAM mais seulement par incréments de 4k.

Vous pouvez également ajouter l'application en cours d'exécution à un groupe de contrôle et régler la permutation afin que l'application soit celle qui a tendance à utiliser le plus le fichier d'échange. Cela ralentira l'application mais épargnera le reste du système.

Il me semble que vous ne pouvez pas par magie "rendre le système réactif". Soit vous encourez la pénalité, soit vous lisez des pages de l'espace de swap dans la mémoire maintenant ou vous les encourez plus tard, mais d'une manière ou d'une autre vous les encourez. En effet, si vous faites quelque chose comme ça, swapoff -a && swapon -avous pouvez ressentir plus de douleur plutôt que moins, car vous forcez certaines pages à être recopiées dans la mémoire qui autrement n'auraient jamais été nécessaires et finalement abandonnées sans être lues (pensez: vous quittez une application pendant que une grande partie de son tas est permutée; ces pages peuvent être entièrement supprimées sans jamais être relues en mémoire).

mais cela efface les pages du swap, elles doivent donc être réécrites la prochaine fois que j'exécute le script.

Eh bien, à peu près n'importe quelle page qui est copiée à partir de l'échange dans la mémoire principale est sur le point d'être modifiée de toute façon, donc si jamais elle devait être retirée pour être à nouveau échangée à l'avenir, elle devrait être réécrite de toute façon. Gardez à l'esprit que le swap est principalement de la mémoire de tas, pas des pages en lecture seule (qui sont généralement sauvegardées sur fichier).

Je pense que votre swapoff -a && swapon -aastuce est aussi bonne que tout ce que vous pourriez trouver.

Il y a une très belle discussion ici http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that ce qui revient à diminuer la permutabilité, avec l'idée que pour augmenter la réactivité perçue du système, il faut éviter d'échanger le code (et c'est ce qui se passe). Ce n'est pas vraiment une réponse à votre question, mais cela peut empêcher le problème d'apparaître (vos applications ne sont tout simplement pas échangées, seules les données inutilisées et le cache de page)