J'ai utilisé unix pendant un bon bout de temps, et ces deux dernières années, j'ai l'impression que l'échange est un anachronisme, mais j'aimerais savoir ce que les autres en pensent.
Mon argument est à peu près ceci (en supposant qu’aucun ulimit global ni aucun twiddling des paramètres de MOO):
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 dont les performances sont optimisées, je pense que la compréhension des limites supérieures de son utilisation des ressources serait la clé du réglage, auquel cas vous savez combien vous avez besoin.
Je ne peux pas imaginer beaucoup de situations (certaines, mais pas beaucoup) dans lesquelles vous suspendez un processus en cours et que celui-ci s'échange pour laisser la place à d'autres choses, mais vous perdriez quand même vos sockets si vous le faisiez. core-dump via gcc ou copier manuellement la mémoire serait fonctionnellement équivalent.
Je ne voudrais certainement pas échanger sur un système embarqué (même s'il dispose d'un RAM plus petit), si vous êtes à court de RAM, je préférerais que mon processus prenne fin plutôt que de déchirer une mémoire flash d'un million d'écrits par secteur. conduire sur un week-end en nivelant les secteurs à l'usure.
Y a-t-il des raisons impérieuses de garder swap autour de la barbe unix?
UPDATE réponses && analyse:
CONFIRMÉ? - fork () nécessite la même quantité de mémoire pour le processus enfant que le processus parent
Modern fork () est une copie sur écriture pour les enfants sous POSIX (en général), mais Linux et FreeBSD en particulier, et j'assume OSX par extrapolation. Je considère cette partie du bagage anachronique que l’échange comporte.
Curieusement, cet article de Solaris affirme que même si Solaris utilise la copie sur écriture avec fork (), vous devez avoir au moins 2x (!) La taille du processus parent en mémoire virtuelle libre pour que fork () ne soit pas soumis à la merde. milieu. Bien que l’élément Solaris masque quelque peu l’argument selon lequel le swap 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 du swap. Puisque. Avouons-le. À ce stade, les personnes qui utilisent réellement Solaris ne sont probablement que des gars d'Oracle. Aucune infraction, Solaris!
CONFIRMED - Les fichiers tmpfs / ramfs peuvent être échangés en tant que conviction lorsque tmpfs / ramfs se remplit
N'utilisez pas tmpfs / ramfs sans limite! Définissez toujours explicitement la quantité de RAM que vous souhaitez que tmpfs / ramfs utilise.
PLAUSABLE - Ayez un petit échange 'juste au cas où'
Un de mes anciens patrons avait l'habitude de dire: "vous ne savez pas ce que vous ne savez pas" - vous ne pouvez pas prendre de décision en vous basant sur des informations que vous n'avez pas encore. C’est un argument plausible pour un échange pour moi, cependant - je suppose que le type de choses que vous feriez pour détecter si votre application est en cours de transfert serait plus lourd que de vérifier pour voir si malloc () réussit ou attraper l’exception de un nouveau () échoué.
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 si quelque chose se gâtait, je préférerais que ce soit une MOO récoltée plutôt que de plonger dans l'enfer. Ce n'est que moi.
BUSTED! - Sous Solaris , l’échange 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 aux gros utilisateurs de tmpfs. Tmpfs partage les ressources avec les données et les segments de pile des programmes en cours d'exécution. L'exécution de très gros programmes peut être affectée si les systèmes de fichiers tmpfs sont proches de leur taille maximale autorisée. Tmpfs est libre d'allouer la totalité de l'espace de swap du système à l'exception de 4 Mo.
Faits et mythes sur les états de swap de Solaris La mémoire virtuelle consiste aujourd'hui en la somme totale de la RAM physique et de l'espace de swap sur le disque. Solaris NE requiert aucune configuration d’espace de swap. Si vous choisissez cette option, une fois que la RAM est pleine, vous ne pourrez plus démarrer de nouveaux processus. .
Je ne sais pas si cela signifie que la carte virtuelle maximale que vous pouvez créer est un échange + échange , ou si vous pouvez toujours faire quelque chose comme mmap (), un fichier plus grand que ram et vous fier à l'initialisation lente de mmap (). peut probablement exécuter Solaris ces derniers temps sans échange, il semble que cela soit moins convivial que d’autres systèmes d’exploitation POSIXy.
BUSTED! Les outils d'hibernation Linux les plus répandus semblent s'appuyer sur l'échange
Par défaut, TuxOnIce semble s'appuyer sur l'échange pour l'hibernation - bien qu'il existe d'autres serveurs. Cependant, si vous n'utilisez pas une boîte qui doit hiberner, je maintiens quand même l'affirmation selon laquelle "swap est anacronistique sur linux"