Pourquoi pas utiliser anacron et mettre un script qui fait swapoff dans /etc/cron.weekly ?
Pourquoi pas ? C’est à réfléchir, car je peux déjà imaginer des cas où cela pourrait être embarrassant. Mais avec le bon intervalle de temps et quelques tests dans le script, cela pourrait en effet être la bonne solution. Merci pour le conseil !
Autre alternative: tu n’actives pas ton swap au boot, et quand tu veux mettre en veille, tu fais un swapon && s2disk ?
Anacron lance les scripts dans /etc/cron.weekly une fois par semaine
l’horodatage du lancement est dans
root@debian:/var/spool/anacron# ls -alrt
total 24
drwxr-xr-x 8 root root 4096 mai 25 2016 ..
drwxr-xr-x 2 root root 4096 déc. 10 10:32 .
-rw------- 1 root root 9 déc. 10 11:06 cron.monthly
-rw------- 1 root root 9 déc. 31 11:34 cron.weekly
-rw------- 1 root root 9 janv. 4 08:53 cron.daily
-rw------- 1 root root 9 janv. 4 11:15 cron.hourly
Tu peux maitriser la periodicité du lancement en supprimant le fichier d’horodatage et en redémarrant
Si tu fais ça un dimanche le swappoff aura lieu chaque dimanche
Il n’y a pas un traitement particulier si swappiness=0 ?
Et puis, en l’absence de pression sur la mémoire, distress devrait être bas.
Normal.
Tu veux dire les données mises en swap avant l’hibernation, par le processus de swap normal ?
Si je ne m’abuse, l’image d’hibernation est supprimée du swap après avoir été utilisée.
L’hibernation n’est pas par elle même juste un swap total ?
Du coup, comme suggère @BigDerf :
C’est pas idiot en effet de penser que la stratégie de remontée en RAM se limite aux données vraiment actives.
Enfin je dis ça…
Qu’entends-tu par “swap total” ?
De ce que j’avais compris, l’hibernation construit une image contenant toutes les données en RAM devant être préservées et l’envoie dans le swap. A la reprise, l’image est lue pour remettre les données en RAM. Mais j’ignore ce qu’il advient des données qui étaient déjà dans le swap. Logiquement, elles y restent.
Je veux dire que l’hibernation, pour ce qui concerne la RAM, ça n’est pas juste un swap forcé de tous les processus actifs ?
Sinon, il y a peut être moyen de savoir ou se situe la lenteur sur la reprise aprés mise en veille, je viens de tomber là dessus, pour le diagnostic:
https://wiki.debian.org/Hibernation#Kernel_testing_facility
Et un contournement au problème plus haut ce petit article : https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition
Je ne pense pas, la doc parle d’une “image d’hibernation”.
Remplacer une partition de swap par un fichier de swap ne fait pas gagner de place sur le disque.
Je fais très rarement un vrai boot. C’est plutôt une longue série de hibernate/resume… Et donc je pense que j’ai toujours besoin du swap au démarrage.
Sur ma machine, l’image de la RAM mise en swap pour l’hibernation n’est jamais nettoyée après la reprise. Si j’ai un swap vide et que je fais une hibernation, alors au retour d’hibernation, mon swap est occupé de 1 à 2 Go. Et si je vais voir à qui appartiennent ces données, elles sont principalement à Firefox et à Gnome, ce qui est conforme à mes activités juste avant d’hiberner. Peut-être est-ce un défaut propre à s2disk ?
Quant à utiliser un fichier swap, vu ce qui m’arrive et dont je parle ici, j’ai bien peur d’avoir un fichier de 10 Go au bout de quelques jours et que finalement, le remède ne soit pire que le mal.
Et sinon je précise que je n’ai aucun problème de lenteur à la reprise. s2disk est assez bien pour cela puisqu’il offre la possibilité d’assigner les quatre cœurs de mon processeur à la décompression et à la lecture de l’image de RAM.
Hier soir e n’ai pas pu hiberner car le swap était plein. Donc j’ai fait un swapoff. Le moniteur d’activité de Gnome montrait que sur quatre CPU (j’ai deux cœurs et l’hyperthreading) seul le CPU1 se chargeait de cette tâche (il restait entre 85 et 100% de charge) tandis que les autres ne faisaient presque rien. Au bout de 7 minutes, seuls 2,5 Go avaient été nettoyés et j’ai fait Ctrl+C car j’en avais marre d’attendre et c’était suffisant pour hiberner.
On voit donc sur le graphique joint le moment de la mise en hibernation à gauche, immédiatement suivi du réveil (aujourd’hui) qui fait certes baisser le swap, mais peu et lentement.
Note: le fait que le swap et la RAM soient au même niveau juste avant l’hibernation est une pure coïncidence.
20 minutes après cette capture d’écran, le swap était à 50% et la RAM à 30%.
J’ai fait quelques recherches pour essayer de comprendre comment le swap était utilisé pour l’hibernation. Il se peut néanmoins que la documentation du noyau et de uswsusp ne soit pas à jour.
Le principe consisterait à “geler” le système et à prendre un “instantané” (snapshot) du contenu de la mémoire à restaurer de façon atomique. Comme cet instantané sera initialement stocké en mémoire, sa taille ne peut excéder la moitié de la taille de la mémoire, de meme que la taille nécessaire dans le swap.
[There should be just one resume partition, for now. You’ll need at most 1/2
of your RAM of free space on it, but in some cases it may be smaller, too.
The s2disk tool may be configured to create quite small snapshot images but
then some contents of the RAM will have to be swapped out before suspend.
Il est possible de spécifier la taille maximum souhaitée de l’instantané. Cette valeur serait à 500 Mo par défaut, mais c’est à confirmer.
If you want to limit the suspend image size to N bytes, do
echo N > /sys/power/image_size
before suspend (it is limited to 500 MB by default).
Le système est ensuite “dégelé” et l’image est écrite dans le swap spécifié (qui peut a priori être distinct du swap actif). Au passage elle peut être compressée et/ou chiffrée.
A la reprise après hibernation, l’image est lue depuis le swap spécifié et restaurée dans la mémoire de façon atomique puis supprimée du swap, et le système va se retrouver dans l’état dans lequel il était lors de la création de l’image.
D’après le premier extrait, je comprends que si le volume des données en mémoire excède la taille maximum souhaitée de l’image, alors une partie de la mémoire va d’abord être swappée selon les mécanismes de swap classiques et ne fera pas partie de l’image d’hibernation, donc sans sa compression. Après la reprise, il est logique de penser que ces données restent dans le swap tant qu’elles ne sont pas demandées.
J’en déduis que le comportement que tu constates peut être causé par une taille d’image trop petite qui forcerait une mise en swap importante à l’hibernation même avec swappiness=0. Pour le vérifier, il faudrait regarder l’occupation du swap avant et après la première hibernation. Elle devrait être nulle avant et non négligeable après.
Si je ne me trompe pas, j’ai donc deux solutions possibles à proposer :
compresser le swap normal en activant zswap comme déjà proposé, ainsi les données non incluses dans l’image d’hibernation bénéficient aussi de la compression et prennent moins de place dans le swap.
augmenter la taille maximum souhaitée de l’image d’hibernation, dans la limite de la moitié de la RAM, afin de diminuer la taille de ce qui devra être swappé de façon classique. Pour s2disk de uswsusp, cela se configure en ligne de commande avec l’option --image_size ou dans le fichier /etc/uswsusp.conf avec le paramètre image size. Par contre cela augmentera probablement le temps de reprise après hibernation.
Par contre chez moi, sur une installation récente (je n’ai pas du tout touché aux paramètres d’énergie ou d’hibernation, s’agissant d’un serveur domestique) j’ai plus de 1.25 Go :
$ cat /sys/power/image_size
1345417216
$ free # à titre indicatif, la valeur dans image_size dépend peut-être de la taille de la mémoire ?
total used free shared buff/cache available
Mem: 3307544 93648 155340 51172 3058556 2969776
Swap: 9862140 8 9862132
(je me rends d’ailleurs compte que j’ai un swap gigantesque)
J’avais prévenu que je soupçonnais certaines informations d’être obsolètes, la taille par défaut de l’image en fait partie.
Edit : Depuis un changement du noyau introduit en 2010, la valeur par défaut est 40% de la RAM, ce qui correspond bien à tes valeurs. A moins que @BigDerf ait forcé une valeur beaucoup plus basse, il y a donc peu de marge pour son augmentation, la valeur maximum étant 50% de la RAM.
la sortie d’hibernation prends combien de temps?
Parce que hiberner pour des onglets Firefox, je comprends pas bien l’interêt.
Mon PC démarre en 40 secondes.
root@debian:/# systemd-analyze
Startup finished in 7.228s (kernel) + 32.927s (userspace) = 40.156s
graphical.target reached after 32.913s in userspace
root@debian:/# uname --all
Linux debian 4.14.0-2-amd64 #1 SMP Debian 4.14.7-1 (2017-12-22) x86_64 GNU/Linux
root@debian:/#
les services les plus long
root@debian:/# systemd-analyze blame
7.781s exim4.service
7.056s ModemManager.service
5.851s NetworkManager-wait-online.service
5.837s accounts-daemon.service
5.765s ufw.service
5.020s laptop-mode.service
4.609s dev-sda1.device
4.177s apparmor.service
4.070s systemd-logind.service
3.770s rsyslog.service
3.728s NetworkManager.service
3.708s iio-sensor-proxy.service
3.469s udisks2.service
3.244s minidlna.service
3.002s winbind.service
2.502s rpcbind.service
2.418s colord.service
2.343s networking.service
2.284s binfmt-support.service
2.144s dnsmasq.service
1.755s polkit.service
1.441s avahi-daemon.service
1.440s wpa_supplicant.service
Vous utilisez tous du swap ?
Cela ne devrait en théorie plus exister bien que Debian freeze lorsque la mémoire est pleine. Il ne gère pas très bien un système sans swap mais bon c’est tellement rare d’utiliser toute la ram que ce n’est pas trop grave.
Après, je ne vois pas trop l’intérêt de passer en hibernation. Si vous vous absentez un moment, éteindre l’écran et le laisser tourner ne prend presque pas de ressources comme le CPU baisse sa fréquence lorsqu’il n’est pas utilisé. Et dès que vous vous absentez plus longtemps, il faut l’arrêter car le démarrage est tellement rapide enfin je n’ai jamais utilisé l’hibernation.
Sur portable, l’hibernation à la fermeture du capot est un must.
Aprés, sur mon poste de travail perso, malgré 64Go de RAM, il y a des moment ou ça swappe, quand j’ai 40 onglets ouverts, plusieurs crawl, des traitements, une grosse VM windows, et la télé en fond.
Alors me passer d’un minimum de swap, non, ça je n’imagine pas.
Et encore moins sur portable.
@PascalHambourg Bravo ! Je te remercie beaucoup car tu m’enlèves une sacrée épine du pied.
le paramètre “image size” peut être réglé à 0 (zéro) pour obtenir l’image la plus petite possible. Ayant un swap qui ne fait que la moitié de ma RAM (et n’ayant pas compris que de toute façon, l’image ne dépasserait pas la moitié de la RAM), je me suis dit que ce serait une bonne idée. Je ne savais pas que ça impliquerait que uswsusp mettrait d’abord tout ce qu’il peut en swap “hors image d’hibernation”. Je pensais tout bêtement qu’uswsusp ferait l’effort maximal en termes de compression, quitte à perdre un peu de temps.
Je viens donc d’essayer de régler la taille de l’image à 4 Go, et effectivement, il n’y a aucun résidu en swap après le réveil.
Par contre, c’est bien plus long puisqu’il compresse et écrit les 800 000 pages et des brouettes au lieux des habituelles 170 000 à 220 000… Mais ce n’est pas un gros problème puisque j’ai un bon SSD et que ce n’est qu’une affaire d’une poignée de secondes.
Merci encore @PascalHambourg pour ta ténacité et ta clairvoyance !
Par curiosité, où as-tu trouvé cette doc détaillée de uswsusp ?
J’ai toujours un paquet de fichiers ouverts dans mon travail, en plus des onglets (souvent des docs ou des applis web). Ce serait impensable pour moi de tous les jours tout sauver, faire la liste de ce qui est ouvert, tout fermer, puis tout rouvrir selon la liste le lendemain… En outre, le temps de redémarrage n’est pas un problème pour moi puisque mon SSD le fait descendre à une vingtaine de secondes (rechargement de tous les fichiers et applis ouverts compris).
Je n’utilise pas de swap, et c’est bien tout le sujet de ce fil puisque j’en ai néanmoins besoin pour l’hibernation.
L’intérêt de passer en hibernation n’est justement pas de “s’absenter un moment” mais de pouvoir éteindre son laptop la nuit ou plusieurs jours (par exemple le weekend) totalement sans perdre un seul pourcent de batterie et de pouvoir le rallumer et reprendre ensuite le travail exactement où on l’a laissé, avec tout ouvert (des dizaines de fichiers dans mon cas) et le curseur exactement à la fin de la dernière phrase tapée.
Moi, c’est l’arrêt de l’ordi que je n’utilise jamais (sauf problème ou mise à jour lourde).