J'utilise Unix depuis un certain temps, et ces dernières années, j'ai eu l'impression que l'échange était un anachronisme, mais je serais curieux de savoir ce que les autres en pensent.
Mon argument est à peu près le suivant (en supposant qu'il n'y a pas d'ulimit global ou de modification des paramètres OOM):
There is little value in swap because if you need to swap out to disk,
odds are it's going to be a vicious cycle where an app will continue
to eat not only real memory, but swap as well until it gets OOM
reaped (_if_ it gets OOM reaped).
If you have swap enabled, it will only prolong this death march to
the detriment of other processes - and in the worst case where the
process is not OOM reaped in a timely manner, grind the system to
a halt.
Without swap, it will probably get OOM reaped sooner (if at all)
Pour tout service optimisé pour les performances, je pense que comprendre les limites supérieures de son utilisation des ressources serait essentiel pour le régler en premier lieu, auquel cas vous savez de combien vous avez besoin.
Je ne peux pas imaginer beaucoup de situations (certaines, mais pas beaucoup) où vous suspendriez un processus en cours d'exécution et qu'il pourrait s'échanger pour faire de la place à d'autres choses, mais vous perdriez toujours vos sockets si vous le faisiez, donc forcer un core-dump via gcc ou copier la mémoire à la main serait fonctionnellement équivalent.
Je ne voudrais certainement pas échanger sur un système embarqué (même s'il peut avoir une plus petite RAM disponible), si vous manquez de RAM, je préférerais que mon processus meure plutôt que de déchirer une mémoire flash d'un million d'écritures par secteur conduisez pendant un week-end en nivelant l'usure des secteurs jusqu'au nœud.
Des barbes Unix ont-elles des raisons impérieuses de continuer à échanger ?
METTRE À JOUR les réponses et l'analyse :
-
CONFIRMÉ ? – fork() nécessite la même quantité de mémoire pour le processus enfant que le parent
Modern fork() est une copie sur écriture pour les enfants sur POSIX (en général), mais Linux et FreeBSD en particulier, et je suppose OSX par extrapolation. Je considère cela comme faisant partie du bagage anachronique que le swap emporte avec lui.
Curieusement, cet article Solaris affirme que même si Solaris utilise Copy-on-Write avec fork(), vous devriez avoir au moins 2x (!) la taille du processus parent dans la mémoire virtuelle libre pour que le fork() ne chie pas au milieu. Alors que l'élément Solaris un peu casse l'argument selon lequel l'échange est un anachronisme - je pense que suffisamment de systèmes d'exploitation implémentent correctement CoW de telle sorte qu'il est plus important de dissiper le mythe que de le marquer comme une justification supplémentaire de l'échange. Depuis. Avouons-le. À ce stade, les personnes qui utilisent réellement Solaris ne sont probablement que des gars d'Oracle. Pas d'offense Solaris !
-
CONFIRMÉ – les fichiers tmpfs/ramfs peuvent être échangés comme une commodité lorsque tmpfs/ramfs se remplit
N'utilisez pas de tmpfs/ramfs sans limite ! Définissez toujours explicitement la quantité de RAM que vous souhaitez que tmpfs/ramfs utilise.
-
PLAUSABLE – Faites un petit échange "au cas où"
L'un de mes anciens patrons avait un grand dicton, "vous ne savez pas ce que vous ne savez pas" - essentiellement, vous ne pouvez pas prendre de décision sur la base d'informations que vous n'avez pas encore. C'est un argument plausible pour l'échange pour moi, cependant - je soupçonne que les types de choses que vous feriez pour détecter si votre application est en train d'échanger ou non seraient plus lourds que de vérifier si malloc() réussit ou attrape l'exception de un échec de new().
Cela peut être utile dans les cas où vous utilisez un ordinateur de bureau et que vous avez un tas de choses aléatoires, mais même quand même – si quelque chose devient fou, je préfère que ce soit OOM récolté plutôt que de plonger dans l'enfer de l'échange. C'est juste moi.
-
ÉCUSTÉ ! – Sur Solaris , échanger est important pour plusieurs raisons
tmpfs - états La quantité d'espace libre disponible pour tmpfs dépend de la quantité d'espace de swap non alloué dans le système. La taille d'un système de fichiers tmpfs augmente pour accueillir les fichiers qui y sont écrits, mais il existe des compromis inhérents pour les gros utilisateurs de tmpfs. Tmpfs partage des ressources avec les segments de données et de pile des programmes en cours d'exécution. L'exécution de programmes très volumineux peut être affectée si les systèmes de fichiers tmpfs sont proches de leur taille maximale autorisée. Tmpfs est libre d'allouer tout sauf 4 Mo d'espace de swap du système.
Réalités et mythes de Solaris sur le swap - États La mémoire virtuelle actuelle consiste en la somme totale de la RAM physique et de l'espace de swap sur le disque. Solaris NE nécessite AUCUN espace de swap pour être configuré. Si vous choisissez cette option, une fois la RAM pleine, vous ne pourrez pas démarrer de nouveaux processus. .
Je ne sais pas si cela signifie que la carte virtuelle maximale que vous pouvez créer est ram + swap , ou si vous pouviez toujours faire quelque chose comme mmap() un fichier plus grand que ram et compter sur l'initialisation paresseuse de mmap(). Bien que vous puissiez probablement exécuter Solaris de nos jours sans échange, il semble que ce soit moins convivial que autres systèmes d'exploitation POSIXy.
-
ÉCUSTÉ ! Les outils d'hibernation populaires de Linux semblent s'appuyer sur le swap
Par défaut, TuxOnIce semble s'appuyer sur l'échange pour l'hibernation - bien que d'autres backends existent. Cependant, si vous n'utilisez pas une machine qui doit hiberner, je soutiendrais toujours l'affirmation selon laquelle "l'échange est anacronique sur Linux"
Réponse acceptée :
Ne confondez pas (le) swap (en tant que zone disque) et (to) swap (en tant que méthode pour déplacer les pages mémoire de la RAM vers le disque et réciproquement).
Un échange excessif est quelque chose à éviter pour des raisons de performances, mais avoir une zone d'échange n'est pas nécessairement un problème.
Sur les systèmes, comme Linux, qui surchargent la mémoire, c'est-à-dire qui permettent aux processus d'allouer plus de mémoire que disponible, manquer de RAM avec pas assez d'échange pour gérer la situation déclenchera le tueur OOM. Vous devez faire confiance à l'algorithme utilisé pour sélectionner le "bon" processus à tuer et accepter qu'un ou plusieurs de vos processus soient tués sans avoir la possibilité de s'arrêter correctement. Voici une analogie célèbre qui explique pourquoi le tueur OOM pourrait ne pas être une bonne idée du tout.
Sur des systèmes comme Solaris, qui ne surchargent pas la mémoire, c'est-à-dire qui s'assurent qu'une réservation de mémoire est toujours adossée à de la mémoire virtuelle, que ce soit en RAM ou sur disque, avoir une zone de swap suffisante est absolument nécessaire sinon une partie potentiellement importante de la RAM sera gaspillé.
Connexes :Linux – Changer la taille de la partition pour 4 Go de RAM ?