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 :