Désactiver l'échange est une bonne idée si
- votre logiciel peut gérer avec élégance les conditions de mémoire insuffisante ou se limiter pour éviter les situations OOM
- avoir des performances constantes est essentiel (lorsque votre système permute, la latence augmente, ce qui peut être suffisamment grave pour le rendre effectivement inutile pour de nombreuses applications)
Ce genre de chose arrive souvent avec les bases de données. Je le vois plus avec les bases de données noSQL, mais les bases de données relationnelles peuvent subir le même défi.
Il n'y a rien dans le système d'exploitation qui nécessite un swap pour être là. Linux gère cela assez gracieusement en tuant le dernier processus qui a demandé de la mémoire. Vous ne voulez pas en arriver là, alors assurez-vous de régler Oracle pour n'utiliser qu'environ 90% de la mémoire afin qu'il en reste pour les démons système et la marge d'erreur. La mémoire « libre » est également utilisée pour mettre en mémoire tampon les E/S du disque, ce qui est un énorme gain de performances. Par conséquent, essayer de consommer plus de mémoire par la base de données elle-même finira par ralentir suffisamment les performances globales du système pour être contre-productif.
Même avec des systèmes qui ont une fraction de la mémoire à partir de la question de savoir si l'application est une base de données ou un cache ou un système similaire, je ne ferais par défaut aucun échange à ce stade.
Autorités
Pour que vous ne vous fiiez pas uniquement à ma parole :
Cassandre
Datastax explique pour Cassandra :
Vous devez désactiver complètement l'échange. Ne pas le faire peut réduire considérablement les performances. Étant donné que Cassandra dispose de plusieurs répliques et d'un basculement transparent, il est préférable qu'une réplique soit tuée immédiatement lorsque la mémoire est faible plutôt que d'être échangée. Cela permet au trafic d'être immédiatement redirigé vers un réplica fonctionnel au lieu de continuer à atteindre le réplica qui a une latence élevée en raison de l'échange. Si votre système a beaucoup de DRAM, l'échange réduit encore considérablement les performances car le système d'exploitation échange le code exécutable afin que plus de DRAM soit disponible pour les disques de cache.
riak
Basho explique à Riak que vous devez :
Idéalement, vous devriez désactiver le swap pour vous assurer que les pages de processus de Riak ne sont pas permutées. La désactivation de l'échange permettra à Riak de planter dans des situations où il manque de mémoire. Cela laissera un fichier de vidage sur incident, nommé
erl_crash.dump, dans le/var/log/riakrépertoire qui peut être utilisé pour déterminer la cause de l'utilisation de la mémoire.
mysql
Percona est assis sur la clôture et fournit des mises en garde utiles pour les deux côtés de la question. MariaDB n'est pas d'accord avec la désactivation de l'échange :
Bien que certains désactivent complètement l'échange et que vous souhaitiez certainement éviter que tout processus de base de données ne l'utilise, il peut être prudent de laisser un peu d'espace d'échange pour au moins permettre au noyau de tomber gracieusement en cas de pic. Le fait d'avoir un échange d'urgence disponible vous permet au moins d'avoir une certaine marge de manœuvre pour tuer tous les processus incontrôlables.
Erreur de serveur
Une réponse bien reçue ici comprend :
Personnellement, je trouve un système swappy pire qu'un système en panne. Un système en panne déclencherait un serveur de sauvegarde de secours pour prendre le relais beaucoup plus tôt. Et dans une configuration active-active (ou à charge équilibrée), un système en panne serait retiré de la rotation beaucoup plus tôt. Encore une victoire pour le système sans échange.
Cette réponse a 22 votes positifs aujourd'hui et a 4 ans. Vous pouvez également y voir d'autres réponses vantant la valeur du swap, mais rien n'indique qu'ils exécutent des bases de données. Ils n'ont pas autant de votes positifs non plus. :)
calmar
Bien qu'ils ne recommandent pas ouvertement de désactiver l'échange, les gars du calmar disent :
Squid a tendance à être un peu gourmand en mémoire. Il utilise la mémoire pour de nombreuses choses différentes, dont certaines sont plus faciles à contrôler que d'autres. L'utilisation de la mémoire est importante car si la taille du processus Squid dépasse la capacité de RAM de votre système, certains morceaux du processus doivent être temporairement permutés sur le disque. L'échange peut également se produire si vous avez d'autres applications gourmandes en mémoire exécutées sur le même système. L'échange entraîne une dégradation très rapide des performances de Squid.
C'est ce que vous ne voulez pas qu'il arrive à votre base de données.
redis
Bien que Redis recommande officiellement l'échange, les utilisateurs ne l'achètent pas :
Désactivez d'abord l'échange - Redis et l'échange ne se mélangent pas facilement et cela peut certainement entraîner des ralentissements.
hadoop
Comme on le voit dans cette réponse avec le plus de votes sur la communauté hortonworks :
Pour les esclaves/travailleurs/hôtes de données qui n'ont que des services distribués, vous pouvez probablement désactiver le swap. Avec les services distribués, il est préférable de laisser le processus/hôte être tué plutôt que de permuter. L'arrêt de ce processus ou de cet hôte ne devrait pas affecter la disponibilité du cluster. Autrement dit :vous voulez "échouer rapidement" et non "dégrader lentement".
[....]
Pour les maîtres , l'échange est également souvent désactivé bien que ce ne soit pas une règle établie par Hortonworks et je suppose qu'il y aura des discussions/désaccords. Les maîtres peuvent être traités un peu comme vous traiteriez les maîtres dans d'autres environnements non Hadoop.
La crainte avec la désactivation de l'échange sur les maîtres est qu'un événement OOM (mémoire insuffisante) pourrait affecter la disponibilité du cluster. Mais cela se produira toujours même avec le swap configuré, cela prendra juste un peu plus de temps. Les bonnes pratiques administrateur/opérateur consisteraient à surveiller la disponibilité de la RAM, puis à résoudre tout problème avant de manquer de mémoire. Maintenir ainsi la disponibilité sans affecter les performances. Aucun échange n'est alors nécessaire.
J'aime cela parce qu'il s'agit d'une application Java, mais cela revient en grande partie aux mêmes conclusions que celles mentionnées ci-dessus à propos des bases de données. En outre, il mentionne la surveillance ce qui est très utile pour régler les applications hautes performances. Si vous n'avez pas de chiffres pour comparer, tout est basé sur des sentiments qui sont plus difficiles à comparer. Créez des graphiques pour chaque métrique mesurable - latence et débit au niveau de l'application jusqu'aux graphiques du processeur, du disque, de la mémoire et du réseau. Ceux-ci fournissent l'essentiel des données réelles sur lesquelles vous devez prendre des décisions.