Optimiser la gestion du swap

Trucs et Astuces
#2

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.

#3

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
#4

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.

#5

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
#6

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

#7

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).

#8

les cache navigateur je les mets en RAM

Firefox
Capture%20d%E2%80%99%C3%A9cran%20du%202019-05-03%2013-27-30

Chromium

/etc/chromium.d# cat cache
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --disk-cache-dir=/tmp/chromium"
#9

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:~#
#10

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?

#11

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.

#12

Merci pour les exemples mieux vaut un bonne image qu’un long discours

#13

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 ?

#14

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é.

#15

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
#16

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)

#17

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]
#18

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
#19

je ne comprends rien à ce que tu racontes
ce n’est pas un exemple c’est mon PC :joy:

2 cpu, deux zones zram, tout va bien
Basta

#20

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
#21

Perso juste un merci @grandtoubab ! Je viens de le mettre en place sur un petit eeepc et franchement ça la libérer et la gestion est plus rapide.