Salut
J’ai eu un peu de mal à mettre en place zswap, la compression lz4 pour optimiser la gestion du swap.
Voici mon petit pense-bête:
1 J'aime
Bonjour,
Je voudrais bien voir l’impact sur les performances. J’imagine que la compression prend du temps CPU, qui pourrait pourtant être utilisé pour faire la bascule SWAP <-> RAM. Du coup il faudrait effectuer quatre tests de performances : normal, RAM compressé, SWAP compressé enfin, RAM et SWAP compressés.
J’ai du mal à me dire que le temps CPU est mieux employé avec de la compression. N’en reste pas moins qu’effectivement, dans l’idéal, il ne vaut mieux pas utiliser le swap. Là comme ça, je dirais que régler son déclenchement est préférable.
je m’en tiens à ce qui disent les gens du noyau
https://www.kernel.org/doc/html/v4.18/vm/zswap.html
Chromium + Spotify + Molotov + Quodlibet + apt update
free -ht
total used free shared buff/cache available
Mem: 3,6Gi 2,0Gi 98Mi 174Mi 1,5Gi 1,2Gi
Swap: 7,5Gi 78Mi 7,4Gi
Total: 11Gi 2,1Gi 7,5Gi
NB: la RAM est aussi utilisée pour /tmp
df -hT
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
udev devtmpfs 1,8G 0 1,8G 0% /dev
tmpfs tmpfs 370M 11M 359M 3% /run
/dev/sda1 ext4 19G 13G 5,2G 72% /
tmpfs tmpfs 1,9G 23M 1,8G 2% /dev/shm
tmpfs tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs tmpfs 1,9G 0 1,9G 0% /sys/fs/cgroup
tmpfs tmpfs 1,9G 4,0K 1,9G 1% /tmp
/dev/sda6 ext4 268G 238G 16G 94% /home
tmpfs tmpfs 370M 28K 369M 1% /run/user/1001
Oui bien entendu, mais comme il n’y a pas de benchmark, difficile de voir le réel impact/gain. Typiquement, est-ce utile pour une machine qui utilise très rarement le swap ? Un exemple tout bête avec mon RPI1, le swap se remplit lors des mises à jour, mais fini par se vider.
C’est à mettre en balance avec le temps que le CPU passe à ne rien faire en attendant la fin des opérations d’entrées-sorties disque qui seraient économisées grâce à la compression.
Le bénéfice éventuel dépend donc de la charge CPU et de du ratio entre la vitesse de compression/décompression du processeur et la vitesse de lecture/écriture du support de stockage.
1 J'aime
Bonjour
Il est vrai qu’il faut aussi solliciter au minimum l’écriture sur les SSD
C’est pour àa que je mets la swapp et le répertoire home sur un disque dur magnétique…
Il faut aussi enlever le cache des navigateurs firefox et chrome…
Dans le fstab, il faut mettre l’option noatime
noatime permet de ne pas mettre à jour la date d’accès sur l’inode pour le système de fichier. Cela peut aider les performances.
Bonne journée
Bonjour,
Merci pour ton sujet, par contre je ne suis pas d’accord avec le point suivant:
Le swap, je pense qu’on est tous d’accord, par contre le /home moi je ne suis pas d’accord. Si le SSD ne sert qu’a lancer le système et les programmes, pourquoi pas, mais c’est dommage de se priver des performances en lecture/écriture.
Je pense que c’est une bonne idée que si on dispose d’une connexion internet rapide ; dans les autres cas ça peut être compliqué. Typiquement sur un PC portable je ne désactive pas le cache disque, mais augmente le cache mémoire. Après j’avoue ne pas savoir quelle est la cuisine interne de Firefox (qu’est-ce qui va dans quel cache et pourquoi).
les cache navigateur je les mets en RAM
Firefox
Chromium
/etc/chromium.d# cat cache
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --disk-cache-dir=/tmp/chromium"
j’ai poussé un peu plus loin la plaisanterie
root@debian:~# swapon -s
Nom de fichier Type Taille Utilisé Priorité
/dev/sda5 partition 7852028 0 -2
/dev/zram0 partition 131068 8600 100
/dev/zram1 partition 131068 8552 100
root@debian:~#
Rebonjour,
Merci pour votre réponse…
En ce qui concerne le /home, ça ce discute.
Par contre j’ai omis de parler du /tmp…
Qu’en pensez vous?
les cache navigateur je les mets en RAM
On évite de swapper mais si on swap on reste en RAM, c’est possible……
ça me fait pensez que lorsque nous n’avions pas trop de place disque que nous mettions des ram disque en mémoire.
Merci pour les exemples mieux vaut un bonne image qu’un long discours
Non, pas forcément. Ça dépend si on veut privilégier la rapidité ou la durée de vie, et dans quelle mesure. Est-ce utile qu’un SSD dure 20 ans ?
Pour ne pas mettre le swap sur SSD ? Non, pas d’accord. Je ne sais plus quel développeur du noyau Linux écrivait qu’il n’y avait pas grand-chose qui méritait plus que le swap d’être sur SSD.
Pourquoi deux swaps compressés en RAM au lieu d’un ?
Je suis d’accord avec ça, seulement le swap, si sollicité régulièrement, va réduire considérablement la durée de vie du SSD. Maintenant comme tu l’as dit :
Je pense simplement que mettre le SWAP ailleurs est un bon compromis. D’autant plus si celui-ci est peu sollicité.
c’est le fonctionnement par défaut, une zone par core
/etc/default/zramswap
# Specifies amount of zram devices to create.
# By default, zramswap-start will use all available cores.
#CORES=1
# Specifies the amount of RAM that should be used for zram
# based on a percentage the total amount of available memory
#PERCENTAGE=10
# Specifies a static amount of RAM that should be used for
# the ZRAM devices, this is in MiB
#ALLOCATION=256
# Specifies the priority for the swap devices, see swapon(2)
# for more details.
#PRIORITY=100
Je ne vois pas le rapport. Pourquoi faudrait-il autant de swaps que de coeurs ?
(je n’écris pas “un swap par coeur” car le script zramswap ne définit aucune affinité entre les swaps et les coeurs)
https://www.kernel.org/doc/Documentation/blockdev/zram.txt
zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram1 lz4 128M 20K 16,1K 20K 2 [SWAP]
/dev/zram0 lz4 128M 184K 180,1K 184K 2 [SWAP]
Précisément : zram alloue déjà un flot de compression par coeur pour chaque périphérique compressé, alors pourquoi créer en plus autant de périphériques que de coeurs, ce qui revient à élever au carré le nombre de flots de compression (2*2=4 dans ton exemple) ?
1 J'aime
je ne comprends rien à ce que tu racontes
ce n’est pas un exemple c’est mon PC 
2 cpu, deux zones zram, tout va bien
Basta
Ben non, ça ne va pas : 2 zones de swap de même priorité=100 en zram avec 2 flots de compression (streams) chacun donc 2*2=4 flots de compression simultanés, soit deux fois plus que de CPU. Donc chaque CPU va devoir inutilement commuter entre deux flots de compression. Une seule zone de swap en zram avec 2 flots de compression me semble suffisante et plus efficace pour exploiter les deux CPU.
1 J'aime