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 <j...@plusquenet.net >> <mailto:j...@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/ > -- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
