Pourquoi une partie de mon espace d'échange est-elle utilisée alors que j'ai encore de la RAM inutilisée?

Plus une curiosité qu'un problème; et, je l'admets, quelque chose d'une question fondamentale embarrassante:

J'ai remarqué qu'à plusieurs reprises, sur ma machine Linux, j'aurais ~ 500 Mo d'espace de swap en cours d'utilisation, même si j'ai ~ 600 Mo de RAM inutilisée.

Ma compréhension naïve de haut niveau était que l'espace de swap ne se déclenche que lorsque la RAM est épuisée.

Je suis allé plus loin et j'ai fait l'hypothèse que cette situation devait être le fait du noyau Linux, car un processus utilisateur qui demande de la mémoire ne le fait que logiquement et n'a aucune idée si cette mémoire est physiquement sauvegardée par la RAM ou l'espace d'échange.

Ce qui conduit à la question: pourquoi le noyau utiliserait-il de manière préventive l'espace de swap? Cela fait-il partie d'un algorithme de réglage des performances? S'agit-il d'un échange vers des parties de disque de la mémoire auxquelles il semble le moins susceptible d'être accédé (un schéma LRU, peut-être)? Si tel est le cas, ne serait-il pas logique de tout laisser dans la RAM, et seulement lorsque vous approchez de l'épuisement, puis et seulement ensuite d'échanger les portions LRU de la RAM vers l'espace d'échange?

Je dois préciser, mon serveur linux a 2 Go de RAM et 2 Go d'espace de swap.

La partie inutilisée de la RAM est en fait utilisée comme cache HDD. Si vous y réfléchissez, vous lisez en fait des parties de votre disque plus souvent que vous accédez à certaines parties de la RAM. Ce qui est logique de mettre cette RAM sur le disque, tout en utilisant de la RAM pour mettre en cache les données du disque dur.

Il est logique d'échanger les choses à l'avance car lorsque vous avez vraiment besoin de la mémoire, vous n'aurez pas à attendre que le noyau ait terminé avec l'accès au disque.

Par exemple, supposons que vous souhaitiez ouvrir une grande image. Lorsque l'image est chargée, il faut 300 Mo de RAM. Si le noyau utilise toute la RAM qu'il peut, le chargement de votre image nécessite que le noyau transfère 200 Mo de la RAM vers le disque. S'il a préalablement vidé la RAM de manière proactive, vous économisez quelques millisecondes.

2 raisons:

1. (@dtrosset) Linux échangera les bits de programmes inutilisés pour donner plus de cache et de tampons.
2. Vous avez peut-être utilisé plus de mémoire dans le passé et échangé des trucs, et cela n'a pas été échangé parce qu'il n'a pas été utilisé, même si ce qui l'a forcé à disparaître a maintenant disparu.

En plus des autres réponses, vous pouvez configurer Linux pour exiger le support de toute mémoire allouée, même si les programmes ne l'utilisent pas.

Cependant, surcharger la mémoire et craindre le tueur OOM ne sont pas des éléments nécessaires de l'expérience Linux. Le simple fait de définir le paramètre sysctl vm / overcommit_memory sur 2 désactive le comportement de surcharge et garde le tueur OOM à distance. La plupart des systèmes modernes doivent avoir suffisamment d'espace disque pour fournir un fichier d'échange suffisant pour la plupart des situations. Plutôt que d'essayer d'empêcher les processus d'animaux de compagnie d'être tués lorsque la mémoire surchargée est épuisée, il pourrait être plus facile d'éviter la situation. [ Répit du tueur OOM ]

Si un programme alloue de la mémoire, le noyau peut simplement marquer plus de pages de swap comme validées. Cette indication est stockée dans le gestionnaire de mémoire du noyau, l'espace disque réel n'est pas encore touché. Jusqu'à ce que cette mémoire soit utilisée, rien ne doit en fait être échangé. S'ils ne sont jamais utilisés, l'utilisation du swap fluctuera sans affecter les performances.

Parce que les processus sont présentés avec leur propre espace d'adressage ou "vue" (c'est ainsi que le swap fonctionne en premier lieu), le noyau a beaucoup de latitude pour gérer cela. En utilisant un exemple de fork également de l'article lié ci-dessus, car il est beaucoup plus susceptible d'avoir des pages de mémoire partagée que d'allouer fraîchement une grande quantité de mémoire inutilisée, la mémoire peut être allouée en copie sur écriture, augmentant le nombre d'utilisation de swap. Lorsqu'il est réellement écrit dans (ce qui pourrait ne pas se produire), ce «swap engagé» peut être remplacé par n'importe quelle RAM inutilisée (augmentant ainsi l'utilisation de RAM et diminuant l'utilisation de swap). Imaginez un processus avec 500 Mo alloués qui se bifurque sur une machine avec tout ou presque toute la RAM utilisée. S'il y a 500 Mo disponibles en swap (et que l'espace disque est bon marché, quelle est la taille de 1% des lecteurs TB actuels?: P), aucune mémoire ne doit être copiée (pourtant,

Ainsi, la possibilité du tueur OOM est évitée, et il est beaucoup plus simple de concevoir la plupart des logiciels en supposant que les allocations de mémoire (y compris les allocations "implicites" via quelque chose comme fork) réussissent ou échouent immédiatement, avec la réalisation pratique que si la mémoire doit être échangé, cela pourrait affecter les performances. Cet impact est presque toujours léger, mais dans le pire des cas, il entraîne un swash thrashing (toujours préférable à un crash brutal du noyau ou à un tueur OOM).

Bien que je ne connaisse pas les détails exacts du fonctionnement du gestionnaire de mémoire Linux, cette réponse est ma propre compréhension généralisée et ce que je me souviens avoir lu au fil des ans. J'ai essayé de rééditer cette réponse, donc une compréhension minimale de la conception du système d'exploitation est requise (c'est considérablement complexe et ce n'est pas quelque chose qui m'intéresse énormément), mais cela semble un peu errer; faites-le moi savoir si vous voyez comment il pourrait être amélioré. D'un autre côté, ce n'est peut-être pas une question aussi embarrassante.