SWAP (Mémoire virtuelle)

[jdh]

@philippe_PMA

Désolé je suis pas convaincu !
Quand on copie la mémoire, on copie forcément toutes les tables du kernel qui tu indiques et qui sont ... en mémoire. Donc pas de problème.


Si le swap est utilisé (commande free : used<>0), c'est qu'il y a des données dedans.
Le swap n'est plus totalement disponible : que se passerait-il si on écrase ces données par une copie de la mémoire ?

Quand Linux se met à swapper, c'est que la mémoire vive est insuffisante.
Donc Linux doit disposer d'une table de pages qui doit avoir un indicateur en mémoire/dans le swap.
Si on lui demande d'hiberner, il faut que le swap soit totalement dispo : il faudrait qu'il ramène les pages dans le swap en mémoire avant d'opérer.

Bon je peux me tromper ...

[jibe]

Si la RAM est suffisante, il ne swappera pas. Mais pour un serveur de bases de données "lourdes et très utilisées", il faudrait une très grande quantité de RAM pour être sûr de ne pas swapper en cas de nombreuses requêtes complexes simultanées. Il est probable que le choix entre le coût de la mémoire et le temps de réponse fasse dans ce cas pencher la balance vers l'augmentation du temps de réponse.

L'apparente contradiction entre Franck78 est sibsib/jdh, c'est que Franck considère que pour remettre en RAM 1Go, il va falloir du temps. Il part donc sur le principe d'un process qui nécessite une grosse capacité de RAM. Or, le cas des bases de données est très différent : chaque requête prend relativement peu de RAM, mais il y a beaucoup de requêtes. On n'a alors pas besoin de faire transiter entre RAM et swap de grosses quantités de données. L'échange est alors assez rapide.

[philippe_PMA]

@philippe_PMA
Désolé je suis pas convaincu !

Je le savais avant que tu l'écrive

Quand on copie la mémoire, on copie forcément toutes les tables du kernel qui tu indiques et qui sont ... en mémoire. Donc pas de problème.


Si le swap est utilisé (commande free : used<>0), c'est qu'il y a des données dedans.
Le swap n'est plus totalement disponible : que se passerait-il si on écrase ces données par une copie de la mémoire ?

Quand Linux se met à swapper, c'est que la mémoire vive est insuffisante.
Donc Linux doit disposer d'une table de pages qui doit avoir un indicateur en mémoire/dans le swap.
Si on lui demande d'hiberner, il faut que le swap soit totalement dispo : il faudrait qu'il ramène les pages dans le swap en mémoire avant d'opérer.

Bon je peux me tromper ...

Je fais une réponse rapide.
Toute la mémoire n'est pas swappée.
Les données essentielles du kernel ne sont jamais swappées. Celles qui permettent de tout retrouver.
Dès que j'ai un peu plus de temps (pas le matin avant d'emmener ma fille à l'écle puis de partir au boulot ...) je recherche l'info.

[jdh]

Je savais aussi.

Un lien intéressant : http://wiki.debian.org/Hibernation/Hibe ... _Partition

Il est intéressant parce qu'il propose
- une solution de swap sans partition swap (au cas où on n'en a pas),
- un bon résumé du contexte,
- une config qui EMPECHE le noyau d'utiliser le swap (pas seulement pour les tables noyau).
Et pourtant il active bien ensuite le swap !

vm.swappiness est un paramètre d'optimisation d'utilisation du swap :
de 0 =pas d'utilisation à 100 =utilisation prioritaire. (Debian = 60 par défaut)
(semble lié à la charge cpu : si la charge est supérieure à swappiness, alors ça swappe)

Je pense qu'il est facile maintenant de trancher la question :
- mettre vm.swappiness=100, redémarrer,
- lancer des services, une base de données, vérifier que le swap est utilisé (free + used>0)
- hiberner
- redémarrer et vérifier ce qui se passe.
(Attention aux données avant !)

Un autre lien intéressant (en français) : http://www.road2mayotte.org/blog/?p=2178

Merci pour cet échange sur un 'petit point' auquel je ne pensais pas !
(Mon point de vue n'est qu'un parmi les autres.)

[Franck78]

Vous avez tous utiliser un live CD un jour. C'est assez insupportable. Et bien voila a quoi ressemblerait probablement un système qui se trainerait 1Go de mémoire lente et utilisée.

@jdh, c'est le processeur qui gère la mémoire. A partir des 386, passage en mode virtuel, l'espace adressable est 4Go pour tous (système/applis).
Quand une adresse tombe, soit le bloc correspond de RAM physque est dispo, soit le proc déclenche une exception PAGE_FAULT, un genre d'irq qui branche sur la gestionnaire de mémoire.

Pas vraiment de table énorme à gérer donc. Tout est fait pas le processeur.

[philippe_PMA]

Concernant l'hibernation fait sur le swap.

Pour rappel
- Toute la mémoire n'est pas swappée (je devrais dire swapable).
- Les données essentielles du kernel ne sont jamais swappées. Celles qui permettent de tout retrouver.

Et j'ajoute, après lecture du code ici https://casper.berkeley.edu/svn/trunk/roach/sw/linux/kernel/power/swsusp.c et de ça http://lwn.net/Articles/179933/, qu'avant écriture sur disque il y a une tentatives de réduction en 5 phases de ce qui doit être écrit sur disque. L'objectif étant d'essayer d'arriver à la taille de réduction demandée autant que possible et on s'arrête dès que c'est atteint (ou à la fin des 5 phases). Et dans la logique qu'il faudra remettre des choses en mémoire à la sortie de l'hibernation on essaye de réduire d'abord ce qui sera le moins utile (et j'imagine re-constructible quand nécessaire), et en dernier ce qui sera le plus utile au sens utilisé le plus rapidement après la sortie de l'hibernation (donc les pages actives).

[philippe_PMA]

...
L'écriture vers le swap suppose que le swap n'est pas utilisée et qu'il est d'une taille au moins égal à la mémoire vive.
(Je vois mal comment un système pourrait écrire sur le swap si le swap est déjà en cours lui-même d'utilisation ...)
...

Finalement, la remarque de jdh n'est pas anodine.

Tout d'abord, lors du chargement d'un programme le fichier est vérouillée (cf. ci-dessous), des structures de données sont créés en RAM ainsi que quelques pages du programme (vous pouvez consulter le code de execve).
Vérouillée : vous pouvez essayer de supprimer le fichier d'un programme sur le disque alors qu'il est en cours exécution vous constaterez que ce n'est pas possible, même en étant root. Il peut être renommé, mais vu qu'il est accédé par son inode ce n'est pas un problème.
Lors d'un défaut de page (PAGE FAULT) la page est recherchée sur le disque, et vu que le fichier du programme (via son inode) est vérouillé par le système il sera toujours là.
L'algo de LRU (Least Recently Used) va gérer un age des pages et, quand cela est nécessaire (pas assez de RAM), il va supprimer les "vieilles" pages des programmes.
Ce que je veux dire c'est qu'il ne va pas les mettre dans le SWAP. Elles sont toujours dans le fichier du programme qui est vérouillé ... donc toujours accessible en lecture.

Du coup, qu'est-ce qui est mis dans le SWAP ?
Dans le SWAP il y a : les dirty pages, soit les pages modifiées et pas écrites. Et c'est encore l'algo LRU qui est utilisé.
Dans les dirty pages il peux y avoir, entre autre, les données du programme (plutôt du processus), les buffers des fichiers, etc.

Du coup, si le SWAP est trop rempli de dirty page et que l'on veut hirberner ... comment fait-on ?
Et bien ça plante !

Du coup, un swap de la taille de la RAM pour assurer une hibernation n'est pas garanti (a moins de ne pas utilisé le SWAP car la RAM est suffisante ...).
Dans le cas où le SWAP est utilisé, il est conseillé : 2 fois la taille de la RAM ...

Tout ça n'enlève pas le fait que dans le mécanisme d'hibernation il y a bien une optimisation de ce qui va devoir être sauvegardé (en 5 phases comme décris ci-dessus).

Un petit lien interressant http://tldp.org/LDP/tlk/mm/memory.html avec une partie des infos ci-dessus.

[jdh]

Le programme qui gère pour le noyau les mouvements entre mémoire et swap est kswapd (semble assez logique comme nom, non ?).

Le lien indiqué détaille assez complètement les méthodes de gestion de pages mémoires avec l'utilisation du swap.
Un autre lien avec plein de schéma d'algo : http://kernel.org/doc/gorman/html/under ... nd013.html

Il s'agit d'un mécanisme "de base" permettant de gérer la ressource mémoire.
Mais heureusement, on a pas besoin d'être expert es gestion mémoire pour installer et faire tourner un Linux ...


Merci pour les infos et la réflexion autour de l'hibernation avec ce lien avec le swap (que j'ignorais).

[philippe_PMA]

Cet article http://distilledb.com/blog/archives/date/2009/02/22/swap-files-in-linux.page indique qu'il y a 4 sortes de page (mémoire) dans Linux :

- Kernel pages. Pages holding the program contents of the kernel itself. Unlike the other flavors, these are fixed in memory once the operating system has loaded and are never moved.
- Program pages. Pages storing the contents of programs and libraries. These are read-only, so no updates to disk are needed.
- File-backed pages. Pages storing the contents of files on disk. If this page has been changed in memory (for example, if it's a document you're working on), it will eventually need to be written out to disk to synchronize the changes.
- Anonymous pages. Pages not backed by anything on disk. When a program requests memory be allocated to perform computations or record information, the information resides in anonymous pages.

- Les pages du kernel sont donc toujours en mémoire. Pour l'hibernation, j'imagine qu'il faut distinguer les pages de codes (rechargeables à partir du file système) qu'il n'est pas nécessaire de sauvegarder lors de l'hibernation et les données (tables et structures de controle) qu'il faudra sauvegarder sur le swap lors de l'hibernation.
- Pour les pages de programmes (dont les librairies), il s'agit uniquement de la partie code. Donc non modifiée et rechargeable à partir du fichier programme.
- Les file-backed pages qui correspondent aux fichiers utilisés par les programmes pour lecture et / ou écriture. Il faut distinguer celles qui sont "propres" (non modifiées) et celles qui sont sales. Celles qui sont sales peuvent se retrouver dans le swap et donc géner l'hibernation. Cf. ci-dessous (slide 32).
- Les pages anonymes celles là doivent être écrites lors de l'hibernation.

Pas mal d'infos détaillées ici http://www.slideshare.net/varunmahajan06/hibernation-linux-2629 :
- Slide 14 : le paramètre /sys/power/image_size est utilisé par l'hibernation. Il s'agit de la taille maximal a essayer d'atteindre pour l'image a écrire sur le swap lors de l'hibernation.
- Slide 32 :
. Le deuxième point indique qu'il y a un un sync des files systèmes, donc les "file-backed pages" sales qui étaient dans le swap en sortent et font de la place ...
. Le cinquième point correspond aux 5 phases du shrinker dont j'ai déja parlé qui permettent de récupérer de la mémoire pour préparer l'image à sauvegarder.
- Slide 39 et 40 : des détails qui montrent que l'algo se soucis d'avoir assez de place (ouf) : Make sure enough free memory for snapshot image is available (39) et "to make sure enought swap is available to save the image" (40).

[philippe_PMA]

Pour alimenter le débat sur la taille du swap, en fesant mes recherches sur l'hibernation, je suis tombé sur un article en 3 parties sur le swap. Le 3ième partie parle de la taille du swap suivant le type d'usage et bien sur termine par ça dépend de l'usage;-)

Je le trouve bien fait. Les 3 trois parties :
http://www.ideaexcursion.com/2009/01/29/all-about-linux-swap-part-1-introduction/
http://www.ideaexcursion.com/2009/02/02/all-about-linux-swap-part-2-management/
http://www.ideaexcursion.com/2009/02/06/all-about-linux-swap-part-3-analysis/