Quelle est la valeur appropriée de vm.swappiness lors de l'utilisation de zram?

J'utilise zram sur mon ordinateur comme un échange compressé avec RAM. Lorsque le système doit échanger quelque chose, le remplacer par un fichier d'échange sauvegardé par zram équivaut plus ou moins à compresser ces données en mémoire pour libérer de l'espace. Cela rend la permutation très rapide la plupart du temps, par rapport à la permutation sur disque. Pour cette raison, je me demande s'il y a des performances à gagner en encourageant le système à échanger les éléments inutilisés de manière plus agressive, car il peut le faire sans vraiment toucher le disque?

Alors, quelqu'un a-t-il joué avec, disons, la mise vm.swappinessà 100 lors de l'utilisation de zram? Serait-ce souhaitable?

sysctl -w vm.swappiness=100

— Ryan C. Thompson
source

C'est une excellente question et je pense que certaines analyses comparatives visent à retirer les opinions et à obtenir les faits ...

— Elder Geek

Bonne idée, et zram aurait pu s'améliorer depuis 2012 quand je l'ai utilisé pour la dernière fois :-)

— Huygens

A fait un petit test et autant que je sache, la mémoire "réservée" pour zram est toujours utilisée comme cache. Si cela est confirmé, je pense qu'il pourrait être judicieux de maintenir le swappiness bas pour éviter les cycles de processeur?

— Vitor

Réponses:

Je ne recommanderais vraiment pas de mettre le swappiness plus haut. Un mécanisme courant dans le noyau est qu'il mettra des pages (morceaux de mémoire) dans le swap pour libérer de la mémoire pour d'autres tâches en cours d'exécution.

Premier "problème" lorsque le noyau veut que n pages soient libérées, m (avec m <n, m est le nombre de pages compressées nécessaires pour contenir n) sont nouvellement créées en RAM, je ne sais pas si cela peut perturber le noyau ou ne pas.

De toute façon, quand vous avez des pages dans le swap, il est possible que vous utilisiez l'application plus tard avec certaines de ses pages dans le swap. Ce que le noyau fait est de ramener ces pages dans la mémoire physique mais ne les supprime pas du swap (qui, avec le swap standard, peut être vu comme une mise en cache , donc lorsque l'application revient en arrière-plan, le noyau n'a pas à réécrire ces pages dans le swap lent). Cependant avec zram ce n'est peut-être pas une astuce sage, car vous avez alors en mémoire les m pages en zram + les n pages qui sont de retour en mémoire!

Le noyau a normalement une "mémoire totale" qu'il peut utiliser pour faire ses affaires. Lorsque vous ajoutez du zram, il ne compte que dans la mémoire de «swap», comme ce serait le cas pour tout swap sur disque, mais il a réduit la «mémoire totale» réelle et ce n'est pas prévu / anticipé par le noyau. Parfois, vous pouvez avoir un comportement étrange et non voulu à cause de cela!

Avec zram, il serait bon que le noyau ne permute pas trop dans cette zone lorsqu'il est sous pression mémoire. Et vous devriez toujours avoir une vraie partition d'échange de disque dur plus grande au moins que la taille maximale de votre zram, afin que le système n'obtienne pas de MOO alors qu'en même temps vous verriez beaucoup d'espace libre comme indiqué par free!

— Huygens
source

zram fournit des périphériques de bloc de RAM. Tout ce qui est écrit sur ces périphériques de bloc est compressé. Si des périphériques de bloc zram sont utilisés comme échange, lorsque le système essaie de déplacer des parties de mémoire à échanger, il déplace effectivement la mémoire d'une partie de la RAM vers une autre, sauf que les données seront compressées avant d'être copiées vers la destination. Cela fonctionne efficacement comme un mécanisme de compression de mémoire bon marché pour améliorer la réactivité dans les systèmes avec des quantités limitées de mémoire. ... Zram est en scène depuis Linux 2.6.33. Dans la version 3.14, zram a été déplacé de la mise en scène vers drivers / block / zram.

— Elder Geek

@ElderGeek exactement! Et je vais prendre un exemple pour illustrer pourquoi ce n'est pas parfait. Le noyau va essayer de supprimer 64 Mo de RAM, il les a mis dans le swap zram. Le bloc de 64 Mo compressé est maintenant de 32 Mo. Le résultat est une diminution de la mémoire de 32 Mo et non de 64 Mo. Maintenant, que se passe-t-il lorsque l'application nécessite le retour de 64 Mo en mémoire, le noyau copie (et ne déplace pas) le morceau en mémoire. Vous avez maintenant 64 Mo de RAM + 32 Mo de zram. Pourquoi copier? Parce que le noyau met en cache les pages comme je l'ai expliqué dans ma réponse. Les deux comportements ne sont pas idéaux. Et quand la mémoire n'est pas bien compressable, c'est encore pire.

— Huygens

Toujours en phase de test. Je pense qu'il doit y avoir un moyen d'ajuster l'algorithme de mise en cache que zram utilise pour libérer la page compressée lorsqu'elle est copiée sur la RAM non compressée.

— Elder Geek

Je l'ai essayé plusieurs fois jusqu'en 2012. À cette époque, mon ordinateur était limité à 1 Go de RAM et lors de la navigation sur Internet, il était douloureusement lent (j'ai généralement 10 à 50 onglets ouverts). Mais depuis lors, je ne l'ai plus jamais utilisé. J'ai plus qu'assez de RAM que je n'utilise plus de swap. Lorsque j'utilisais zram avec Firefox à l'époque, j'ai rapidement commencé à "échanger" étant donné le peu de RAM que j'avais. Et rapidement, j'ai eu un système qui ne répond pas avec de nombreux plantages. Sans zram, c'était douloureusement lent mais stable au moins. Mon problème était que probablement il compressait / décompressait constamment les pages mémoire.

— Huygens

Oui, mes résultats ont été quelque peu similaires, sur un système de 8 Go, j'ai pu forcer un MOO en lançant plusieurs VM pendant un travail d'encodage. Avez-vous une expérience avec zswap? Cela semble une alternative viable sur la base de ce que j'ai lu.

— Elder Geek

Réponse courte: vm.swappiness=100est la valeur appropriée pour zram (au moins sur Debian Stretch avec Linux 4.9, je pense que c'est la meilleure valeur)

Je teste déjà vm.swappiness=100pour moi.

Je pense que vous pouvez faire un test simple pour déterminer la valeur qui vous convient le mieux.

J'ai aussi fait un autre programme simple pour tester cette question. x Sur ma machine, une vm.swappinessvaleur très faible (telle que vm.swappiness=1) causera un problème de réactivité évident.

À propos SwapCachedde /proc/meminfo:

Tout d'abord, essayez vm.page-cluster=0, cela peut peut-être réduire certains inutiles SwapCacheddu swap-in.

SwapCached peut accélérer le zram de la même manière que le périphérique de swap non-zram

SwapCached Il peut être réutilisé (gratuitement) si nécessaire:

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$

— analphabète
source

Les pages doivent être échangées (sur le disque) lorsque la mémoire est pleine. Si vous utilisez la mémoire pour créer un espace pour échanger des pages lorsque la mémoire est pleine, on pourrait penser que cela bat le but, sauf si la compression fait la différence (et il serait alors naturel de compresser la mémoire directement au lieu de passer par échanger). Je suppose qu'il faudrait comparer cela, car les ordinateurs sont de plus en plus rapides à compresser et à décompresser par rapport à la vitesse de la mémoire.

— Alexandre
source

J'ai trouvé le swap soutenu par zram lui-même très utile lorsque le système manque de mémoire. Cela m'a évité à quelques reprises de me retrouver complètement coincé dans l'échange d'enfer et de devoir redémarrer (j'analyse de grands ensembles de données, j'ai donc besoin de la mémoire, tous les 24 Go). Je me demande simplement si la vm.swappinessvaleur est réglée pour le swap sauvegardé sur disque et si je dois la changer si j'utilise principalement le swap soutenu par zram.

— Ryan

"de plus en plus rapide"? La compression à la volée est plus performante que les E / S de disque directes depuis plus de la dernière décennie (ce ne sera jamais plus rapide que l'accès à la mémoire - ce n'est pas le but)

— symcbean

symcbean, vous avez oublié "par rapport à la vitesse de la mémoire". Où est le désaccord?

— Alexander

Je pense que le point de symcbean est que le but des pages sauvegardées en mémoire compressée (zram) est de remplacer l'échange sur un support physique. La raison pour laquelle il n'est pas «naturel de compresser directement la mémoire» est qu'il serait compliqué pour les applications de devoir déterminer quelles parties de sa mémoire pourraient être compressées et quand; le sous-système VM est un endroit beaucoup plus facile à implémenter. Les charges de travail qui bénéficient de zram ont des pages qui ne sont pas dans le jeu de travail et peuvent être facilement compressées.

— Daniel Papasian