2014-09-29 17:03 GMT+02:00 Jean Weisbuch jean@plusquenet.net:
Désactiver complètement le swap est rarement une bonne idée, il est plus prudent d'en laisser un peu avec le swapiness très bas (ou à 0).
Bonjour,
L'ayant en production et n'ayant jamais rencontré de problématique dans mes utilisations (principalement des bases de données et du caching HTTP), as-tu des exemples où, malgré une utilisation calibrée du serveur (calcul précis des utilisations des programmes installés, pas de multi-utilisateur, un seul jeu de services par serveur, etc), cela pose problème ? Sous quelle forme cela se manifeste-t'il ?
Merci ! Cordialement,
Bonjour,
cela fait des années que je ne mets plus de swap sur les serveurs Linux/Unix (production ou pas).
En gros, si le serveur n'a plus de RAM : - s'il a du swap disque : il va l'utiliser et 95% du temps ça va écrouler les perfs de TOUS les services du serveur - s'il n'a pas de swap, ca met la pression sur le garbage collector jusqu'à ce qu'il tue des services, donc ça n'impacte qu'une partie du serveur
Ca peut s'entendre de mettre du swap sur des serveurs avec disques SSD, où là, le swap représente une alternative viable à la RAM, mais pour l'instant je n'en ai pas eus sous la main.
++
Le 29 septembre 2014 17:25, Aurélien footplus@gmail.com a écrit :
2014-09-29 17:03 GMT+02:00 Jean Weisbuch jean@plusquenet.net:
Désactiver complètement le swap est rarement une bonne idée, il est plus prudent d'en laisser un peu avec le swapiness très bas (ou à 0).
Bonjour,
L'ayant en production et n'ayant jamais rencontré de problématique dans mes utilisations (principalement des bases de données et du caching HTTP), as-tu des exemples où, malgré une utilisation calibrée du serveur (calcul précis des utilisations des programmes installés, pas de multi-utilisateur, un seul jeu de services par serveur, etc), cela pose problème ? Sous quelle forme cela se manifeste-t'il ?
Merci ! Cordialement, -- Aurélien Guillaume
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
Je confirme, pas de swap sur les serveurs. Les SSD pourquoi pas, mais quitte à investir autant ajouter de la RAM. Par contre, zram est excellent sur les serveurs, même si au départ c'était plutôt pour les clients légers...
Cordialement,
Christophe
Personnellement, je préfère mettre un peu de swap (genre 2Go) et un swappiness à 5, accompagné d'un monitoring sur la swap. Parce que swap ou pas, et quelque soit la quantité de RAM, Linux va tout consommer, ou du moins un serveur qui consomme 99% de la RAM est "normal", ce qui empêche de monitorer une consommation excessive de mémoire.
Si la sonde détecte 10 ou 20% de conso swap, c'est qu'un service devient trop gourmant et bien souvent on peut intervenir sans qu'un seul service soit ralentit ou coupé.
La swap ne me sert que de tampon provisoire de quelques minutes à quelques petites heures, et à tuner correctement les services. Rare sont les cas ou la swap a été entièrement consommée, très rare, et dans ce cas on se retrouve dans le même cas qu'avec un serveur sans RAM.
D'autant que PostgreSQL consomme du buffer cache, c'est normal, on ne peut donc pas forcément monitorer autrement ...
Cette technique je l'utilise avec succès avec un peu tout: MySQL, PostgreSQL, des trucs Java, des services standard, ...
My 2 cents,
Le 29 septembre 2014 19:48, David Amiel pouyoux.achats@gmail.com a écrit :
Bonjour,
cela fait des années que je ne mets plus de swap sur les serveurs Linux/Unix (production ou pas).
En gros, si le serveur n'a plus de RAM :
- s'il a du swap disque : il va l'utiliser et 95% du temps ça va écrouler
les perfs de TOUS les services du serveur
- s'il n'a pas de swap, ca met la pression sur le garbage collector
jusqu'à ce qu'il tue des services, donc ça n'impacte qu'une partie du serveur
Ca peut s'entendre de mettre du swap sur des serveurs avec disques SSD, où là, le swap représente une alternative viable à la RAM, mais pour l'instant je n'en ai pas eus sous la main.
++
Le 29 septembre 2014 17:25, Aurélien footplus@gmail.com a écrit :
2014-09-29 17:03 GMT+02:00 Jean Weisbuch jean@plusquenet.net:
Désactiver complètement le swap est rarement une bonne idée, il est plus prudent d'en laisser un peu avec le swapiness très bas (ou à 0).
Bonjour,
L'ayant en production et n'ayant jamais rencontré de problématique dans mes utilisations (principalement des bases de données et du caching HTTP), as-tu des exemples où, malgré une utilisation calibrée du serveur (calcul précis des utilisations des programmes installés, pas de multi-utilisateur, un seul jeu de services par serveur, etc), cela pose problème ? Sous quelle forme cela se manifeste-t'il ?
Merci ! Cordialement, -- Aurélien Guillaume
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 29/09/2014 20:10, Greg a écrit :
Personnellement, je préfère mettre un peu de swap (genre 2Go) et un swappiness à 5, accompagné d'un monitoring sur la swap. Parce que swap ou pas, et quelque soit la quantité de RAM, Linux va tout consommer, ou du moins un serveur qui consomme 99% de la RAM est "normal", ce qui empêche de monitorer une consommation excessive de mémoire.
La RAM est toujours occupée à 100%, mais on peut monitorer le rapport (buffer+cache)/(RAM totale). En dessous de 25%, penser à l'upgrade.
Si jamais le swap sert sur un serveur, ça finira toujours pareil, serveur à genoux, reboot.
Cordialement,
Christophe
Pas dans le cas de PostgreSQL, et j'imagine que c'est le cas pour d'autres services.
Le 29 septembre 2014 20:20, Christophe c.baegert-listes@lixium.fr a écrit :
Le 29/09/2014 20:10, Greg a écrit :
Personnellement, je préfère mettre un peu de swap (genre 2Go) et un swappiness à 5, accompagné d'un monitoring sur la swap. Parce que swap ou pas, et quelque soit la quantité de RAM, Linux va tout consommer, ou du moins un serveur qui consomme 99% de la RAM est "normal", ce qui empêche de monitorer une consommation excessive de mémoire.
La RAM est toujours occupée à 100%, mais on peut monitorer le rapport (buffer+cache)/(RAM totale). En dessous de 25%, penser à l'upgrade.
Si jamais le swap sert sur un serveur, ça finira toujours pareil, serveur à genoux, reboot.
Cordialement,
Christophe
Tout dépends de l'utilisation du serveur et de sa quantité de mémoire mais en manière générale il est plus prudent d'avoir de la swap et le swapiness très bas ou à 0 histoire d'éviter d'avoir des soucis en cas de dépassement exceptionnel en ayant des OOM kills qui sont rarement idéales pour l'applicatif (et ses utilisateurs).
Il n'est pas toujours possible (ou pas forcément de manière précise et simple) de limiter pour chaque démon/script la mémoire utilisée, surtout si le serveur ne sers pas qu'à faire tourner qu'un gros service, il y à aussi la possibilité qu'après une mise à jour ou modification, l'utilisation et la gestion de la mémoire ne soit pas la même ou qu'un/des nouveau(x) cache(s) aient fait leur apparition.
Si l'on fais tourner par exemple un serveur MySQL/MariaDB et qu'on à configuré tout les caches et buffers pour utiliser idéalement la RAM en utilisation normale, il y à quand même des buffers qui seront alloués dynamiquement à chaque requête et parfois l'utilisation de tables temporaires en mémoire qui elles aussi peuvent avoir des tailles très variables ; la gestion de la mémoire et du cache est également différente en fonction du moteur de stockage utilisé et de l'utilisation ou non de directio/O_DIRECT (bypass du cache de fichiers par le système) pour InnoDB et TokuDB par exemple. Une solution très utilisée est également de mettre en tmpfs le répertoire temporaire de MySQL/MariaDB qui contiendra les tables temporaires ne pouvant être maintenue en mémoire par le service lui même, certaines opérations ALTER nécessitant de recréer la table ou les index peuvent créer de tels fichiers qui en fonction de la table d'origine risqueront d'être plus gros que la taille de la mémoire libre si le serveur est déjà configuré pour utiliser idéalement la mémoire en utilisation normale, il faut donc configurer le tmpfs pour pouvoir faire de l'over-provisionning et se retrouver à utiliser la swap dans ces cas de figure car il n'est pas possible de modifier le/les répertoire(s) temporaire(s) sans redémarrer le démon, ce qui n'est pas forcément idéal et nécessite une planification supplémentaire à chaque opération de ce type. Autre petit exemple de mise en swap qui peux surprendre : si MySQL/MariaDB 5.5 tourne sur un serveur multi-socket à architecture NUMA sans interleaving d'activé, il ne pourra pas utiliser plus que la quantité de mémoire disponible sur un CPU pour le buffer pool d'InnoDB, il swappera le reste (sauf si innodb_buffer_pool_instances est supérieur à 1 (qui est sa valeur par défaut sur 5.5)).
Si en plus il y à plus d'un serveur SQL (ou autre démon(s) et scripts gourmands) tournant sur la machine et n'utilisant pas forcément la mémoire au même moment de la journée ou par burst, il sera en effet possible de limiter à chacun sa quantité de mémoire pour que si tous utilisent à 100% leurs ressources allouées, la mémoire du serveur ne soit pas saturée mais au final en limitant drastiquement la mémoire allouable par chacun en cas de burst et limitant plus qu'autre chose les performances.
Quant aux serveurs à genoux dès que ça swap, tant que le swapiness est bas et que la mise en swap est exceptionnelle, cela ne ralentira sensiblement qu'au moment ou le seuil est dépassé mais pas forcément plus qu'avoir à relancer complétement le démon en ayant les clients qui se reconnectent tous d'un coup après un timeout, un recovery (et potentiellement des tables corrompues à réparer) à effectuer et les caches à re-provisionner.
A savoir qu'il est simple et rapide de flusher la swap si la mémoire est de nouveau disponible.
En conclusion, je pense qu'il est toujours plus prudent d'avoir un peu de swap qui ne sera idéalement pas utilisée mais qui servira de sécurité, je n'ai jamais eu de soucis avec cette approche et la gestion du swap est bonne sur les kernels récents.
ps: à propos de NUMA et PostgreSQL, je ne connais pas assez PostgreSQL pour être affirmatif mais il est peut être possible que le cache d'une seule table ne soit fait que par un seul processus à la fois et si la table en mémoire prends plus que la mémoire libre sur le processeur sur lequel il tourne, de se retrouver à swapper.
Le 29/09/2014 17:25, Aurélien a écrit :
2014-09-29 17:03 GMT+02:00 Jean Weisbuch <jean@plusquenet.net mailto:jean@plusquenet.net>:
Désactiver complètement le swap est rarement une bonne idée, il est plus prudent d'en laisser un peu avec le swapiness très bas (ou à 0).Bonjour,
L'ayant en production et n'ayant jamais rencontré de problématique dans mes utilisations (principalement des bases de données et du caching HTTP), as-tu des exemples où, malgré une utilisation calibrée du serveur (calcul précis des utilisations des programmes installés, pas de multi-utilisateur, un seul jeu de services par serveur, etc), cela pose problème ? Sous quelle forme cela se manifeste-t'il ? Merci ! Cordialement, -- Aurélien Guillaume
Pour ma part, j'évite au maximum de mettre du swap, sauf à ne pas avoir suffisament de mémoire physique.
En cas de surconsommation, je préfère avoir un service tué par oom qu'un serveur inaccessible
M'enfin
On 29/09/2014 21:45, Jean Weisbuch wrote:
Tout dépends de l'utilisation du serveur et de sa quantité de mémoire mais en manière générale il est plus prudent d'avoir de la swap et le swapiness très bas ou à 0 histoire d'éviter d'avoir des soucis en cas de dépassement exceptionnel en ayant des OOM kills qui sont rarement idéales pour l'applicatif (et ses utilisateurs).
Il n'est pas toujours possible (ou pas forcément de manière précise et simple) de limiter pour chaque démon/script la mémoire utilisée, surtout si le serveur ne sers pas qu'à faire tourner qu'un gros service, il y à aussi la possibilité qu'après une mise à jour ou modification, l'utilisation et la gestion de la mémoire ne soit pas la même ou qu'un/des nouveau(x) cache(s) aient fait leur apparition.
Si l'on fais tourner par exemple un serveur MySQL/MariaDB et qu'on à configuré tout les caches et buffers pour utiliser idéalement la RAM en utilisation normale, il y à quand même des buffers qui seront alloués dynamiquement à chaque requête et parfois l'utilisation de tables temporaires en mémoire qui elles aussi peuvent avoir des tailles très variables ; la gestion de la mémoire et du cache est également différente en fonction du moteur de stockage utilisé et de l'utilisation ou non de directio/O_DIRECT (bypass du cache de fichiers par le système) pour InnoDB et TokuDB par exemple. Une solution très utilisée est également de mettre en tmpfs le répertoire temporaire de MySQL/MariaDB qui contiendra les tables temporaires ne pouvant être maintenue en mémoire par le service lui même, certaines opérations ALTER nécessitant de recréer la table ou les index peuvent créer de tels fichiers qui en fonction de la table d'origine risqueront d'être plus gros que la taille de la mémoire libre si le serveur est déjà configuré pour utiliser idéalement la mémoire en utilisation normale, il faut donc configurer le tmpfs pour pouvoir faire de l'over-provisionning et se retrouver à utiliser la swap dans ces cas de figure car il n'est pas possible de modifier le/les répertoire(s) temporaire(s) sans redémarrer le démon, ce qui n'est pas forcément idéal et nécessite une planification supplémentaire à chaque opération de ce type. Autre petit exemple de mise en swap qui peux surprendre : si MySQL/MariaDB 5.5 tourne sur un serveur multi-socket à architecture NUMA sans interleaving d'activé, il ne pourra pas utiliser plus que la quantité de mémoire disponible sur un CPU pour le buffer pool d'InnoDB, il swappera le reste (sauf si innodb_buffer_pool_instances est supérieur à 1 (qui est sa valeur par défaut sur 5.5)).
Si en plus il y à plus d'un serveur SQL (ou autre démon(s) et scripts gourmands) tournant sur la machine et n'utilisant pas forcément la mémoire au même moment de la journée ou par burst, il sera en effet possible de limiter à chacun sa quantité de mémoire pour que si tous utilisent à 100% leurs ressources allouées, la mémoire du serveur ne soit pas saturée mais au final en limitant drastiquement la mémoire allouable par chacun en cas de burst et limitant plus qu'autre chose les performances.
Quant aux serveurs à genoux dès que ça swap, tant que le swapiness est bas et que la mise en swap est exceptionnelle, cela ne ralentira sensiblement qu'au moment ou le seuil est dépassé mais pas forcément plus qu'avoir à relancer complétement le démon en ayant les clients qui se reconnectent tous d'un coup après un timeout, un recovery (et potentiellement des tables corrompues à réparer) à effectuer et les caches à re-provisionner.
A savoir qu'il est simple et rapide de flusher la swap si la mémoire est de nouveau disponible.
En conclusion, je pense qu'il est toujours plus prudent d'avoir un peu de swap qui ne sera idéalement pas utilisée mais qui servira de sécurité, je n'ai jamais eu de soucis avec cette approche et la gestion du swap est bonne sur les kernels récents.
ps: à propos de NUMA et PostgreSQL, je ne connais pas assez PostgreSQL pour être affirmatif mais il est peut être possible que le cache d'une seule table ne soit fait que par un seul processus à la fois et si la table en mémoire prends plus que la mémoire libre sur le processeur sur lequel il tourne, de se retrouver à swapper.
Le 29/09/2014 17:25, Aurélien a écrit :
2014-09-29 17:03 GMT+02:00 Jean Weisbuch <jean@plusquenet.net mailto:jean@plusquenet.net>:
Désactiver complètement le swap est rarement une bonne idée, il est plus prudent d'en laisser un peu avec le swapiness très bas (ou à 0).Bonjour,
L'ayant en production et n'ayant jamais rencontré de problématique dans mes utilisations (principalement des bases de données et du caching HTTP), as-tu des exemples où, malgré une utilisation calibrée du serveur (calcul précis des utilisations des programmes installés, pas de multi-utilisateur, un seul jeu de services par serveur, etc), cela pose problème ? Sous quelle forme cela se manifeste-t'il ?
Merci ! Cordialement, -- Aurélien Guillaume
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour à tous, pour ma part, je pense que la désactivation complète du swap est une mauvaise idée surtout sur un serveur. Les "erreurs de visée" de l'oom m'ont laissé un souvenir peu agréable. Vis à vis de l'usage mémoire, je préfère un système qui met en swap quelques démons très peu sollicités pour faire de la place au cache disque. Ce que je veux, c'est limiter les entrées/sorties aléatoires pas forcément les supprimer. Si avec un swap-in/swap-out par jour je peux éviter des millions de lectures disque, ça me va. Bien entendu, je ne traiterais pas forcément de la même manière une machine virtuelle avec 1G ou un serveur de base de donnée avec un demi To de mémoire. Cordialement, Luc.
On 30/09/2014 08:19, Luc Bégault wrote:
Bonjour à tous, pour ma part, je pense que la désactivation complète du swap est une mauvaise idée surtout sur un serveur. Les "erreurs de visée" de l'oom m'ont laissé un souvenir peu agréable. Vis à vis de l'usage mémoire, je préfère un système qui met en swap quelques démons très peu sollicités pour faire de la place au cache disque. Ce que je veux, c'est limiter les entrées/sorties aléatoires pas forcément les supprimer. Si avec un swap-in/swap-out par jour je peux éviter des millions de lectures disque, ça me va. Bien entendu, je ne traiterais pas forcément de la même manière une machine virtuelle avec 1G ou un serveur de base de donnée avec un demi To de mémoire. Cordialement,
Bonjour,
En ce qui me concerne je suis partisan de la désactivation du SWAP et du dimensionnement généreux de la quantité de RAM des machines...
Les seules machines sur lesquelles j'ai 32Mo (oui, Mo) de SWAP: Qq serveurs postgresql (8.2) qui se comportent de manière étrange sans swap (plus aucune requète SQL n'est traitée après qq heures d'uptime). Après ajout du swap, plus de problème.
Le coût actuel de la RAM étant relativement bas, il ne faut pas se priver.
Personne n'a parlé de KSM [1] ?
Laurent
Hello tout le monde,
De mon coté j'ai un autre point de vue, surtout avec la généralisation de la virtualisation.
Pour un serveur physique, il est clair que le stockage est souvent pas cher, et ne pas mettre de swap est des fois pas une bonne idée.
Par contre la règle (vieille !) de mettre en swap 2 fois la RAM est assez stupide, surtout quand on a des machines avec 64G ou plus... Le temps que vas mettre l'OS a faire des I/O sera tellement trop élevé que ça va exploser le système et que de toute façon ça va se terminer par un downtime ou des gens qui vont râler.
Donc de mon coté en général je ne mets pas plus que 10Go de SWAP (quelque soit l'OS) quand on est sur du bare métal.
A l'opposé sur de la machine virtuelle, je deviens plutôt facho.
En effet, du swap sur n VM sur UN disque ou une baie SAN/NAS/iSCSI/whatever deviens un truc de qui est largement dangereux et peux foutre en l'air un hyperviseur avec 20 vm en l'air juste parce qu'on a un vm qui a décidé de swapper comme un malade (genre la VM qui fait 20GO de swap, déjà vu ce genre de délires).
Donc en général, je fais la chose suivante :
- OS M$ Windows : swap = 0 - OS Linux : swap entre 0 et 1G (en général je mets 512Mo) - OS BSD : swap 512Mo
Pourquoi ces limites de swap ? Et bien sur ESXi il y a le balloon en RAM, on peux garantir un niveau de ram et "laisser l'hyperviseur" ranger le bordel si besoin.
Donc typiquement, si mon appli en VM a besoin de 1G, je mets 2Go avec une garantie de 1,2Go. Pas de swap, pas de pb....
Et puis je préfère un Out of Memory Kill que d'avoir perdu la main sur les 20 vm de cet hyperviseur.
Dernier point, la dedup (a priori) en RAM existe sur pas mal d'hyperviseur, donc il est potentiellement intéressant de faire 1VM = 1 service que de faire une VM avec 1000 services comme sur un serveur physique...
Xavier
-
Aurélien -
Christophe -
David Amiel -
frsag＠jack.fr.eu.org -
Greg -
Jean Weisbuch -
Laurent CARON -
Luc Bégault -
Xavier Beaudouin