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/