Il pourrait être utile d'augmenter /proc/sys/vm/page-cluster (par défaut :3).
Depuis la documentation du noyau (sysctl/vm.txt ):
cluster de pages
page-cluster contrôle le nombre de pages jusqu'auquel des pages consécutives sont lues à partir du swap en une seule tentative. Il s'agit de la contrepartie de swap pour la lecture anticipée du cache de page. La consécutivité mentionnée n'est pas en termes d'adresses virtuelles/physiques, mais consécutive sur l'espace d'échange - cela signifie qu'elles ont été échangées ensemble.
C'est une valeur logarithmique - le mettre à zéro signifie "1 page", le mettre à 1 signifie "2 pages", le mettre à 2 signifie "4 pages", etc. Zéro désactive complètement la lecture anticipée.
La valeur par défaut est trois (huit pages à la fois). Il peut y avoir quelques petits avantages à régler ceci sur une valeur différente si votre charge de travail est intensive en échange.
Des valeurs plus basses 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 des pages consécutives que la lecture anticipée aurait apportées.
La documentation ne mentionne pas de limite, vous pouvez donc peut-être définir cette valeur absurdement élevée pour que tout le swap soit relu très bientôt. Et bien sûr, ramenez-le ensuite à une valeur saine.
Il me semble que vous ne pouvez pas "rendre le système réactif à nouveau" comme par magie. Soit vous encourez la pénalité, soit vous relisez des pages de l'espace d'échange dans la mémoire maintenant, soit vous l'encourez plus tard, mais d'une manière ou d'une autre, vous l'encourez. En effet, si vous faites quelque chose comme swapoff -a && swapon -a alors vous vous sentirez peut-être plus douleur plutôt que moins, parce que vous forcez certaines pages à être recopiées en mémoire qui n'auraient autrement jamais été nécessaires et finalement abandonnées sans être lues (pensez :vous quittez une application alors qu'une grande partie de son tas est échangée ; ces pages peuvent être complètement rejeté sans jamais être relu en mémoire).
mais cela efface les pages du swap, elles doivent donc être écrites à nouveau la prochaine fois que j'exécute le script.
Eh bien, à peu près n'importe quelle page qui est copiée de swap dans la mémoire principale est sur le point d'être modifiée de toute façon, donc si jamais elle devait être déplacée pour être à nouveau échangée à l'avenir, elle devrait être écrite à nouveau dans swap 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 -a l'astuce est aussi bonne que tout ce que vous pourriez trouver.
Vous pouvez essayer d'ajouter les programmes qui vous intéressent le plus à un groupe de contrôle et d'ajuster la permutation afin que la prochaine fois que l'application s'exécute, les programmes que vous ajoutez soient 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 cela est probablement simplement le comportement "stop and start" lorsque de nombreuses pages d'un programme sont en swap et que le programme doit continuellement s'arrêter pour échanger ses pages dans la RAM, mais uniquement par incréments de 4k.
Alternativement, vous pouvez ajouter l'application en cours d'exécution à un groupe de contrôle et ajuster la permutation afin que l'application soit celle qui a tendance à utiliser le plus le fichier d'échange. Cela ralentira l'application mais cela épargnera le reste du système.