SWAP pour hibernation avec beaucoup de RAM

Tags: #<Tag:0x00007f63f5f94650>

Bonjour tout le monde :grinning:,

La question peut paraître basique, mais j’ai un PC qui possède 32GB de RAM pour virtualiser. J’avais lu (le lien de ma source est cassé) que pour déterminer la taille du SWAP, il faut doubler la taille de la RAM + 2 GB pour l’hibernation. Dans ce cas j’obtiendrais un fichier ou une partition de 66GB.

Pour avoir l’hibernation, suis-je contraint par cette taille ou est ce que je peux réduire ?

Est-ce envisageable de mettre un tel SWAP sur un disque mécanique au regard du temps de sortie de veille (ou autres latences), ou je ferais mieux de le mettre sur le SSD qui contient mon Debian au regard de son usure et de sa taille moindre ?

Merci d’avance pour vos avis éclairés :grinning_face_with_smiling_eyes: !

Avec adelphité,
lnj

Non, tu doit pouvoir mettre le contenu de la RAM dans cet espace, si ta mémoire RAM est utilisé à 80/90% tu devra avoir autant d’espace à disposition.

Tu peux le mettre sur du disque mécanique, tout dépendra de ton besoin de sortie d’hibernation rapide ou non.
Pour rappel l’usure des SSD n’est plus la même qu’au début des premiers SSD pour des disque de qualité :wink:

1 J'aime

Oui donc avec 32 GB de RAM => 32 GB de SWAP, et donc nul besoin de doubler ni d’ajouter les 2GB. Tu confirmes ?

Ça dépend ce que tu appelles rapide : 30s pour avoir un système à nouveau opérationnel me semble acceptable, si sur HDD ça prend 1 minute c’est trop !

[edit]Au cas où, mon CPU : Intel(R) Core™ i5-4590 CPU @ 3.30GHz[/edit]

Cette formule ne repose sur rien de sérieux et relève de la poudre de perlimpimpin.
Il n’y a pas de formule magique universelle pour La taille du swap. La taille utile est la somme de l’occupation maxi du swap en fonctionnement et de la quantité de données en mémoire qui devra être sauvegardée lors lors de l’hibernation, sachant qu’une partie non négligeable de la RAM (typiquement la moitié) est utilisée comme mémoire cache qui n’ira pas besoin d’être sauvegardée. Les valeurs affichées par la commande free dans la colonne « utilisé » sont une bonne approximation.

Oui, si possible. À moins d’hiberner 10 fois par jour, l’usure n’est pas un problème. En revanche la taille peut l’être si tu as « mieux » (du contenu plus souvent utilisé) à mettre sur ce SSD.

2 J'aime
user@host:~$ free --mega
               total       utilisé      libre     partagé tamp/cache   disponible
Mem:           33533        7278       18766        1019        7488       24761
Partition d'échange:       1022           0        1022

Là présentement j’ai 7 GB utilisés, mais si je fais tourner quelques VMs en particulier des systèmes Windows, ce que tu dis avec la mémoire cache NON à sauvegarder, c’est que je n’atteindrais pas les 32 GB « utiles » mais plutôt 16 GB. Dans ce cas je peux créer un SWAP de 16 GB. C’est bien ça ?

Aussi, théoriquement si j’oublie d’éteindre une VM ou de la sauvegarder avant d’hiberner ça ne fera pas dépasser le SWAP, tu confirmes ?

Ce sera 2-3 hibernations/jour, sinon du SWAP to RAM.
En tout cas je vais faire le test avec un HDD pour voir si le temps de réveil est acceptable comparativement à un SSD.

Dans cet ordre de grandeur, plus un peu de marge.

Tu veux dire « suspend to RAM » ?

Heu oui :grinning_face_with_smiling_eyes:

Me concernant je ne mets jamais de SWAP sur mes SSD. Sur mes machines perso sous Linux, avec 32 Gb de RAM, je n’en ai pas besoin.

Plus un SSD est fragmenté en différentes partitions, mois la fonction TRIM aura de marge de manœuvre pour harmoniser l’usure de tous les secteurs du disque en question, donc plus vite il va claquer. C’est une bonne raison pour moi d’éviter tant que possible d’utiliser une partition SWAP. Si j’en avais absolument besoin, à titre personnel je pencherai plus pour l’utilisation d’un fichier SWAP plutôt que d’une partition pour les raisons expliquées ci-dessus ou alors je la placerai sur un disque dur à plateau.

Part ailleurs, aujourd’hui les machines démarrent tellement vite que la fonction d’hibernation est quasiment devenue obsolète…

Les conseils globaux disent d’utiliser une SWAP comprise entre 1 à 2 fois à notre quantité de RAM pour éviter des crash systèmes, en cas de risques de dépassement de la taille maximale de la RAM.

Lorsque je m’occupais de ma stations de travail dédiée à la CAO-DAO, les fournisseurs de solutions logicielles nous conseillait de régler la SWAP sur la même quantité de RAM intégrée aux machines, ils disaient que cela faisait gagner en performances. Mais bon dans les faits on gagnait peut-être quelques microsecondes…

Ça fait beaucoup de marge.

Si la mise en hibernation de la machine hôte est transparente pour les VM, alors je dirais peu importe comment celles-ci gèrent la mémoire ; la mémoire allouée à l’hyperviseur pour les VM est gérée comme la mémoire allouée aux autres programmes.

Pour quelle raison ? J’ai beau me creuser la tête, je ne vois pas en quoi le nombre de partitions influe sur le nivellement de l’usure.

L’utilisation d’un fichier de swap au lieu d’une partition ne fait aucune différence puisque le noyau accède directement au SSD sans passer par le système de fichiers. D’ailleurs tous les types de systèmes de fichiers ne le permettent pas. D’autre part c’est sale, et encore plus s’il est utilisé pour l’hibernation (obligation de déterminer et passer l’offset physique du fichier de swap dans la partition au noyau pour la reprise après hibernation).

Sauf quand on a besoin de conserver l’état complet du système, de garder des application ouvertes. Les VM, par exemple.

Moi non plus mais c’est pour l’hibernation

Pour ma part, hors production j’ai pris l’habitude de tout mettre dans une unique partition.

Note : je viens de m’apercevoir que j’ai dérogé à mon habitude (je devais être dans la lune), puisque l’installation sur mon SSD indique que j’ai oublié de supprimer la partition de SWAP qui fait 1GB (wouéééé on va aller loin!)

Comme je l’ai dit plus haut c’est pour pouvoir reprendre ma session en cours (applis, docs, etc.)

De plus, j’avais assemblé une belle machine (CPU : Intel(R) Core™ i5-4590 CPU @ 3.30GHz), mais bon elle a quand même presque 9 ans donc MES performances ne sont peut être pas les performances dont tu parles. Ceci dit, elle démarre quand même assez vite (idem pour s’éteindre, un plaisir :stuck_out_tongue:

@PascalHambourg a l’air de dire que c’est une légende urbaine …

Tu monterais à 20 GB ?

Bonne nouvelle, alors :slightly_smiling_face:

Si moi je vois un avantage. Un fichier ça se recrée n’importe où et ça ne prend pas beaucoup de temps, mais une partition ça peut être galère à agrandir (pousser la partition suivante, etc.) ou à récupérer l’espace une fois réduite ; je dis ça par ma propre expérience. Pour le réveil, pour ce qui des calculs d’offsets, c’est pas si compliqué (comme par exemple ici)

Descendre, tu veux dire (de 32 à 20) ? La marge doit prendre en compte le degré d’incertitude sur la taille nécessaire. Dans le doute, mieux vaut prendre trop large que trop serré.

Pas n’importe où : comme je l’ai écrit plus haut, certains systèmes de fichiers ne supportent pas les fichiers de swap, et d’autres comme btrfs imposent des restrictions. Quant au temps de création, il dépend aussi du type de système de fichiers, notamment si celui-ci supporte la préallocation ou non.

Entièrement d’accord, c’est pourquoi il y a d’autres options :

  • Gérer plusieurs partitions de swap au lieu d’en redimensionner une. Par contre l’image d’hibernation ne peut être écrite que dans un seul swap.
  • Si l’espace disque est suffisant, surdimensionner la partition de swap.
  • Utiliser LVM qui facilite le redimensionnement.
1 J'aime

Si tu as une partition swap disons de 32 Gb, formatée en systèmes de fichiers swap, la fonction TRIM va choisir les secteurs qui ont étés le moins écrits sur cet espace de 32 Gb seulement pour y stocker des données… Après quand les secteurs de cette partition commenceront à s’user et à rendre l’âme, alors les secteurs de secours commenceront à être exploités.

Par rapport aux autres partitions « / » et « /home », la swap usera beaucoup plus rapidement ton disque sur cette partition bien précise. Ne penses-tu pas ?

L’utilisation d’un fichier swap est un tout petit peu moins rapide qu’une swap traditionnelle mais comme il est sur une bien plus grosse partition, l’usure est mieux répartie.

A de rares exception prêt en effet tel une VM… ou pour les flemmards. Part ailleurs ça consomme du courant électrique pour pas grand chose tant que ça reste en veille.

Me suis mal exprimé. Tu dis que 16 GB de SWAP est trop juste pour 32 GB de RAM et qu’il faut un peu plus de 16 GB. Moi je propose 32 GB pour être tranquille, tu me dis que je vise large. Du coup combien mettrais tu ?

OK ! Je ne connais pas beaucoup btrfs du coup je te fais confiance. Dans mon cas j’utilise principalement pour le moment Ext3-4 pour le système et j’envisage ZFS pour la redondance des données et aussi pour le système mais n’ai pas encore testé, en ce cas il faudra que je vois comment le SWAP est possible par fichier (sinon je me rabattrai sur une partition de SWAP)

Gérer plusieurs SWAP semble pratique effectivement.

Surdimensionner me parait une bonne solution (=> x2 + 2GB indiqué en OP)

LVM ça ne m’a jamais vraiment inspiré. Que se passe t-il si un disque physique d’un VG tombe en rade, on perd le tout ? Je suis plus orienté vers les systèmes de fichier comme ZFS et pourquoi pas BTRFS qui ont beaucoup de points communs, entre autres le RAID logiciel.

Je n’arrive pas à me séparer de « /home » que je ne formate pas en cas de réinstallation du système… c’est un confort dont j’aurais peine à me passer !!

avec un ssd ça doit foncer :slight_smile:

Je ne pense pas qu’il voulait parler de légende urbaine à propos de la swap, mais plutôt des + 2 GB pour l’hibernation. Après la swap est utilisée normalement quand il n’y a pas assez de Ram à disposition, de sorte à éviter les kernels panic.

Le swap n’est pas un système de fichiers. Ça ne se monte pas.

La fonction TRIM ne choisit rien du tout. Elle sert à marquer les secteurs logiques qui ne contiennent plus de données valides pour l’OS (fichier effacé, page de swap remplacée…).

Il n’y a pas de secteurs de secours dans un SSD. Il y a plus de blocs physiques que de blocs logiques, certains blocs physiques sont alloués aux blocs logiques et les autres sont soit vides et en attente d’écriture et d’allocation, soit en attente d’effacement. Le nivellement de l’usure consiste à allouer en priorité les blocs qui ont subi le moins de cycles d’écriture/effacement.
D’autre part un SSD ne sait rien des partitions, fichiers ou autres découpages logiques, donc il ne peut pas faire la différence entre une partition de swap et un fichier de swap. Pour lui ce sont seulement des ensembles de blocs.

Non, c’est pareil qu’une partition sauf si le fichier est très fragmenté.

L’hibernation n’est pas une mise en veille, c’est un arrêt total de la machine.

Non, je n’ai pas dit cela. J’ai dit que le swap pour l’hibernation devait être dimensionné en fonction de la quantité de mémoire maximum utilisée en prenant une marge, indépendamment de la taille de la RAM . Tu as dit que c’était 16 Go. Je laisse la détermination de la marge à ton appréciation.

Ext4 est un système de fichiers classiques qui supporte bien les fichiers de swap. Je n’ai pas d’expérience avec ZFS mais compte tenu de ses caractéristiques (copy-on-write, déduplication, instantanés, sous-volumes…) je ne serais pas étonné que les fichiers de swap ne soient pas supportés. Mais on peut mettre le swap dans un zvol, donc je ne vois pas l’intérêt d’utiliser un fichier de swap sur ZFS.

Pas très pratique pour l’hibernation en revanche, voir la réserve dans mon message précédent.

Les LV qui ont des extents alloués sur un PV manquant sont inaccessibles. Mais agréger l’espace de plusieurs disques n’est qu’une des façons d’utiliser LVM disques, on peut aussi l’utiliser sur un seul disque pour allouer l’espace à la place des partitions. Pour la redondance, LVM supporte les LV en RAID ou bien peut utiliser des ensembles RAID md comme PV.

Je parle de la formule swap = RAM * 2. Quant aux +2 Go, je ne vois pas le rapport avec l’hibernation.

Oui ! J’aimerais aussi avoir un montage de partition dédiée pour mon /home. Typiquement quand j’aurais avancé sur la mise en place d’un RAID 5 ou 6 logiciel par ZFS, je ferais ce montage. Ce qui me manque pour le moment c’est des gros disques de mêmes tailles (genre un RAID 5 de 16 TB avec 3 HDDs de 8 TB) mais mes finances ne me permettent pas de faire n’importe quoi. Mais chaque chose en son temps.

Voui c’est assez confortable :stuck_out_tongue: et en plus je peux mettre à jour pour un CPU plus rapide (carte mère MSI H97M-G43 (MS-7924))

Je ne savais pas qu’on pouvait faire du RAID logiciel avec LVM. Et pour ce qui est du RAID md dans un projet de NAS, on me l’a très fortement déconseillé par rapport à la corruption de données et on m’a recommandé d’utiliser ZFS à la place

[edit]Entre temps @PascalHambourg a répondu => comme je ne suis pas sûr de la « marge à mon appréciation », je vais créer un SWAP de la taille de la RAM sur HDD ; si je vois que c’est vraiment pénalisant au niveau des délais (hibernation + réveil), je le passerais sur le SSD[/edit]

Bon je pense qu’on a fait le tour, vous m’avez bien aidé.

Je viendrais vous faire un retour quand je l’aurais testé.

Les hyperviseurs habituellement ne font pas d’hibernation, sauf sur des VM sur des workstations et encore.

Tout dépend de l’utilisation que l’ont fait. BRTFS n’est pas forcement adapté à tout et n’importe quoi, idem ZFS.
On peut très bien avoir du LVM sur du raid en passant. Voir même du LVM sur du LUKS sur du RAID.

Perso je ne garde que les données de mon home sur une sauvegarde (en l’occurrence sur un NAS). J’évite ainsi de conserver de la m… d’une installation à une autre.

Plusieurs swap pour un même système n’est pas une bonne idée. J’ai eu le problème avec des installation automatique en multiboot. A partir du deuxième système installé celui-ci était susceptible d’utiliser le swap de l’autre système. Un bon moyen d’avoir des problèmes.

Utiliser des swaps multiples est un cas spécifique d’utilisation; inutile dans un fonctionnement classique.

Ce n’est pas forcement vrai. Là où je bosse nous avons des centaines de systèmes sur des raid 5 et raid 1 par mdadm.
Ca dépend en fait de l’utilisation des données de sa quantité, du niveau de performance demandé et/ou subit.
J’ai un ELK qui tourne sur un système dont la partie système est en RAID1 SSD/NVME et les données sur un RAID 5 sans aucun soucis depuis 4 ans. Il reçoit la totalité des logs de tous les autres système et aplications (parefeux, surficata, etc…).
Le seul cas où je n’utilise pas de RAID bien évidement c’est sur une VM. Mais par contre j’ai des stockages de VM qui sont en RAID5 (pas beaucoup de VM dessus ceci dit).

Et donc si j’oublie d’éteindre ou sauvegarder l’état d’une VM alors que je demande l’hibernation, est ce que ça va passer ?

Pour info, ma virtu personnelle c’est du Qemu/KVM.