Bon apparemment il reste quelques zones d’ombre… Après quelques heures de travail qui n’ont donné lieu à aucune occupation du swap, j’ai refait un hibernate/resume, et j’obtiens tout de même 450 Mo d’occupation du swap, et ça augmente de 1 Mo par minute… 110 Mo sont explicables par cette cochonnerie de double serveur X de Gnome (le gdm “mort” est mis en swap presque entièrement) mais le reste tient encore pour moi de l’ésotérique.
Dans /usr/share/doc/uswsusp, comme là où se trouve la documentation de la plupart des paquets installés.
La documentation du noyau concernant l’hibernation se trouve dans /usr/share/doc/linux-doc-{version}/Documentation/power. Il faut installer le paquet linux-doc-{version}. Attention, comme on l’a vu certaines informations peuvent être obsolètes, la documentation du noyau n’étant pas systématiquement mise à jour lors de modifications des fonctionnalités.
Note : à la différence des donnée swappées qui doivent être écrites dans le swap une seule fois et qui peuvent y rester ensuite tant qu’elles ne sont pas demandées, les données mises dans l’image d’hibernation doivent être écrites et lues dans le swap à chaque hibernation, même si elles ne sont pas utilisées. Une image d’hibernation plus grosse occasionne donc plus d’écritures sur le SSD à chaque hibernation. L’alternative consistant à activer la compression du swap avec zswap n’aurait pas cet inconvénient, sans aller jusquà réduire au minimum la taille de l’image à nouveau.
Ça pourrait aider à comprendre d’enregistrer et comparer le contenu de /proc/meminfo avant et après chaque hibernation, ainsi que la taille de l’image d’hibernation.
J’essaierai de rapporter les données de/proc/meminfo, même si moi-même e n’y comprends pas grand chose (je vois un VmallocTotal de 34 To qui me donne le vertige, je n’ai aucune idée de ce que ça peut bien vouloir dire).
Sinon, j’ai un script qui m’indique quels processus ont du swap et en quelles quantité. Habituellement c’est principalement Firefox et les divers composants de Gnome. Sauf que maintenant il semble qu’il y ait seulement quelques Mo entreposés par des processus (en additionnant tous les VmSwap de tous les “/proc/[0-9]+/status” ) et je n’arrive pas à identifier les éventuels propriétaires des quelques centaines d’autres Mo.
Je prends note du conseil pour limiter les accès au swap avec zswap.
En fait, ce n’est pas une zone d’ombre mais c’est parfaitement logique. Comme @PascalHambourg l’a dit, s2disk construit un instantané de la RAM et place cet instantané lui-même dans la RAM. Il faut donc que la RAM ne soit pas occupée à plus de 50%, pour placer l’instantané dans l’autre moitié. Si, comme ça a été mon cas récemment, plus de la moitié de la RAM est occupée, alors s2disk déplace le surplus vers le swap et ne traite que la moitié qui reste en RAM. Lors du réveil, le “surplus” qui a été placé en swap y demeure, jusqu’à ce qu’il soit explicitement rappelé en RAM quand un processus en a besoin.
Je ne suis pas certain de ce raisonnement, mais en tout cas il concorde avec les chiffres que j’observe. 4,5 Go occupés (sur 8 Go) => 450 Mo en swap au réveil. 5 Go occupés => 1 Go en swap au réveil.
Je ne sais pas si c’est possible, tant la gestion des mémoires par le noyau a l’air complexe et subtile, mais si ça l’était, j’aurais apprécié que les concepteurs de s2disk prévoient un rappel des données swappées juste après le réveil. Le fait qu’il ne semble pas exister d’autres moyens de rappeler les données swappées que de faire swapoff me fait penser que ce n’est peut-être tout simplement pas possible. 
A ma connaissance c’est le noyau et lui-seul qui décide ce qui est swappé et dé-swappé.
Je ne pense pas que ce soit s2disk lui-même qui swappe les données qui ne peuvent pas tenir dans l’image d’hibernation. Je pense que s2disk se limite à indiquer au noyau la taille d’image dont il a besoin, et le noyau se débrouille pour allouer l’espace nécessaire, en swappant si nécessaire.
De même, je doute qu’à la reprise, resume (s2disk ne gère que la mise en hibernation, pas le réveil) ait la possibilité de demander au noyau d’extraire les données swappées avant l’hibernation. J’ignore si le noyau a un mécanisme pour dé-swapper par anticipation quand les conditions s’y prêtent (mémoire libre suffisante, activité disque faible). On constate sur ton graphisme que l’occupation du swap diminue progressivement après le réveil, mais est-ce dû seulement au rappel des pages effectivement accédées et à la suppression des pages obsolètes, ou bien y a-t-il un rechargement par anticipation ?
slt, chez moi c’est le contraire ma ram est de 4 Go et ma swap de 8 Go mais confronté au même symptôme, avant l’hibernation la swap n’est pas du tout utilisée mais lors du réveil d’hibernation, le système est lent car des programmes continuent à swapper alors que la ram n’est même pas utilisée à la moitié de sa capacité.
si je désactive la swap avec swapoff -a alors le système retrouve sa vitesse normale.
mais ce qui est curieux, lorsque je désactive le swap, la commande
for file in /proc/*/status ; do awk ‘/Tgid|VmSwap|Name/{printf $2 " " $3}END{ print “”}’ $file; done | grep kB | sort -k 3 -n
m’indique toujours que certains programmes ont toujours des données inscrites en swap
...... authdaemond 1060 48 kB authdaemond 958 48 kB log 1006 52 kB pulseaudio 1497 52 kB gvfsd-dnssd 27353 56 kB Thunar 27771 60 kB tomboy 31953 60 kB gvfs-afc-volume 1388 64 kB opera 10485 68 kB wpa_supplicant 1081 76 kB xfce4-power-man 1334 76 kB xfce4-volumed 1450 76 kB cups-browsed 944 84 kB applet.py 1457 88 kB panel-4-systeml 1352 88 kB panel-5-xfce4-c 1332 92 kB opera 10489 96 kB upowerd 1363 96 kB ModemManager 757 104 kB xfconfd 1291 104 kB dbus-daemon 1276 108 kB polkit-gnome-au 1452 112 kB lightdm 1223 116 kB rsyslogd 770 124 kB xfsettingsd 1305 124 kB scp-dbus-servic 1652 128 kB firefox-esr 10166 148 kB kactivitymanage 1367 168 kB gvfsd-trash 1398 180 kB lightdm 984 200 kB
C’est vrai que c’est étonnant, mais ce sont des valeurs très faibles, quasiment négligeables.
Juste un petit retour… zswap fonctionne très bien, du coup j’ai voulu essayer de le booster en utilisant la compression lz4, d’après des indications glanées sur les forums. Ça fonctionne très bien, mais elle fait planter la reprise après une hibernation, donc ce n’est pas une option pour moi.
Merci à tous en tout cas.
Rectification (j’avais oublié un update-grub):
zswap fait systématiquement planter la reprise après hibernation. L’image est récupérée, mais (d’après ma maigre compréhension des messages de sys.log), systemd s’emmêle les pinceaux avec son service systemd-logind, et ferme les deux sessions existante (d’abord la Debian-gdm sur tty1, puis ma session utilisateur sur tty2).
Je n’ai fait qu’ajouter le paramètre zswap.enabled=1 dans la ligne des options passées au noyau du fichier /etc/default/grub. Et je pense que les bons paquets sont installés puisque suite à un boot normal, le sys.log indique bien que mon swap est géré avec zswap… À moins qu’il existe un autre paquet pour des fonctions plus avancées comme l’hibernation. Par exemple, j’ai vu un paquet zswap-tools qui n’est pas installé sur ma machine…
N’utilisant ni zswap ni l’hibernation, je ne pourrais pas t’aider beaucoup plus. En tout cas je ne vois pas le rapport avec systemd-logind.
zswap est géré par le noyau, je ne vois pas pourquoi il faudrait un programme userland. Je ne vois pas de paquet zswap-tools dans l’archive Debian et un moteur de recherche web ne trouve rien non plus.
Désolé, je me suis emmêlé… c’était lz4-tools…
Et effectivement, je ne comprend pas pourquoi l’activation de zswap vient forcer les sessions à fermer ni pourquoi systemd-logind y déverse autant de messages d’erreur. Il doit y avoir une récation en chaîne. En fait, systemd se plaint de ne pas trouver le dossier /lib/systemd/systemd-sleep, et il est vrai que je n’ai qu’un dossier /lib/systemd/system-sleep. Cependant, ça ne semble pas poser de probème quand zswap est désactivé…
Bon de toute façon, je vais en rester là pour le moment, j’ai déjà appris pas mal de trucs et je sature. je continuerai peut-être l’enquête dans quelques semaines/mois.
En tout cas merci !
Par acquit de conscience, je suis tout de même allé sur l’article wikipedia de zswap, et tout s’éclaire…
zswap intercepte les pages qui doivent être swappées, les compresse et les garde en RAM (du moins autant que possible). Or dans Debian, d’après ce que j’ai compris du mécanisme de double session (qui a l’air de ne pas embêter que moi), la session primaire Debian-gdm qui reste inactive dans la plupart des cas est celle dont les pages seront les premières à aller en swap. Cela se confirmait sur mon système quand je listais les processus (avec leur propriétaire) qui plaçaient leurs données en swap.
Donc ma théorie c’est qu’avec zswap, les données de la session primaire Debian-gdm sont les premières à se faire compresser et qu’ensuite l’image de la RAM pour l’hibernation les contient telles quelles. Sous cette forme, il est possible qu’elles ne soient pas récupérables à la reprise après un hibernate, ce qui fait planter la session primaire, qui entraîne avec elle sa session fille où l’on est censé entrer le mot de passe pour retrouver sa session (d’où les messages d’erreur avec systemd-logind, peut-être).
Bref… Bonne soirée.