Bon ben voilà, je l’aurais parié que les dév. kernel ont implémenté ça de façon un peu plus intelligente que d’attendre d’avoir besoin de RAM pour mettre en swap, et s’éviter ainsi de l’écriture disque pile au moment où on a aussi besoin de lire.
C’est expliqué avec un joli graphe un peu plus bas. Si j’ai bien compris, lorsque la RAM qui peut être allouée descend en dessous d’un certain seuil on écrit des données en swap. Donc bien avant de se retrouver totalement à cours de RAM. Si jamais l’allocation est très importante et que la quantité libre de RAM continue de baisser jusqu’à un second seuil, alors seulement à ce moment, l’allocation est limitée par la vitesse d’écriture du swap. Le but du jeu est que ce dernier cas de figure ne se présente que rarement avec les bons jeux de paramètres. Sur la Debian, ce serait /proc/sys/vm/min_free_kbytes qui permettrait d’agir sur la quantité de RAM libre en-dessous de laquelle le système doit commencer à mettre en swap. Il est fixé à ~45 Mo par défaut (soit plus qu’une Debian avec postfix, apache, cyrus-imap au démarrage).
Enfin bref : le swap est là pour libéré la RAM, et le coût de mise en swap est limité vis-à-vis de la demande en mémoire vive (tant qu’elle est raisonnable). De toute façon systemd ne change rien à ce principe : une fois qu’il a lancé le service c’est le swap qui prendra le relais sur une machine qui en a besoin ; systemd va se contenter d’introduire un délai dans ce comportement. Donc je vois pas bien pourquoi se priver du service du swap dans l’intervalle démarrage de la machine — premier accès au service, alors que c’est ce même swap qui entrera en jeu pour toute la durée de vie du service qui est rarement utilisé.
[^] # Re: Merci
Posté par BB . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 10.
Bon ben voilà, je l’aurais parié que les dév. kernel ont implémenté ça de façon un peu plus intelligente que d’attendre d’avoir besoin de RAM pour mettre en swap, et s’éviter ainsi de l’écriture disque pile au moment où on a aussi besoin de lire.
C’est expliqué avec un joli graphe un peu plus bas. Si j’ai bien compris, lorsque la RAM qui peut être allouée descend en dessous d’un certain seuil on écrit des données en swap. Donc bien avant de se retrouver totalement à cours de RAM. Si jamais l’allocation est très importante et que la quantité libre de RAM continue de baisser jusqu’à un second seuil, alors seulement à ce moment, l’allocation est limitée par la vitesse d’écriture du swap. Le but du jeu est que ce dernier cas de figure ne se présente que rarement avec les bons jeux de paramètres. Sur la Debian, ce serait /proc/sys/vm/min_free_kbytes qui permettrait d’agir sur la quantité de RAM libre en-dessous de laquelle le système doit commencer à mettre en swap. Il est fixé à ~45 Mo par défaut (soit plus qu’une Debian avec postfix, apache, cyrus-imap au démarrage).
Enfin bref : le swap est là pour libéré la RAM, et le coût de mise en swap est limité vis-à-vis de la demande en mémoire vive (tant qu’elle est raisonnable). De toute façon systemd ne change rien à ce principe : une fois qu’il a lancé le service c’est le swap qui prendra le relais sur une machine qui en a besoin ; systemd va se contenter d’introduire un délai dans ce comportement. Donc je vois pas bien pourquoi se priver du service du swap dans l’intervalle démarrage de la machine — premier accès au service, alors que c’est ce même swap qui entrera en jeu pour toute la durée de vie du service qui est rarement utilisé.