Où va la mémoire restante de vm.overcommit_ratio?

Si je désactive la surcharge de mémoire en définissant vm.overcommit_memorysur 2, par défaut le système permettra d'allouer la mémoire jusqu'à la dimension de swap + 50% de mémoire physique, comme expliqué ici .

Je peux changer le rapport en modifiant le vm.overcommit_ratioparamètre. Disons que je l'ai défini à 80%, donc 80% de la mémoire physique peut être utilisée.

Ma question est:

• que fera le système avec les 20% restants?
• pourquoi ce paramètre est-il requis en premier lieu?
• pourquoi je ne devrais pas toujours le régler à 100%?

Que fera le système avec les 20% restants?

Le noyau utilisera la mémoire physique restante à ses propres fins (structures internes, tables, tampons, caches, etc.). Le paramètre de sur-engagement de mémoire gère les réservations de mémoire virtuelle des applications utilisateur, le noyau n'utilise pas de mémoire virtuelle mais physique.

Pourquoi ce paramètre est-il requis en premier lieu?

Le overcommit_ratioparamètre est un choix d'implémentation conçu pour empêcher les applications de réserver plus de mémoire virtuelle que ce qui sera raisonnablement disponible pour elles à l'avenir, c'est-à-dire lorsqu'elles accèdent réellement à la mémoire (ou du moins essaient de le faire).

La définition overcommit_ratiode 50% a été considérée comme une valeur par défaut raisonnable par les développeurs du noyau Linux. Cela suppose que le noyau n'aura jamais besoin d'utiliser plus de 50% de la RAM physique. Votre kilométrage peut varier, la raison pour laquelle il est réglable.

Pourquoi ne devrais-je pas toujours le régler à 100%?

Le paramétrer à 100% (ou toute valeur "trop ​​élevée") ne désactive pas de manière fiable le sur-engagement car vous ne pouvez pas supposer que le noyau utilisera 0% (ou trop peu) de RAM.

Cela n'empêchera pas les applications de se bloquer car le noyau pourrait de toute façon préempter toute la mémoire physique dont il a besoin.

La définition du ratio à 100% ne réservera aucun espace pour les pages sauvegardées sur fichier ou les allocations dans le noyau telles que le code du noyau, les tampons réseau, etc.

Les structures dans le noyau seront allouées malgré tout, provoquant une surcharge. Ils sont généralement limités individuellement (par exemple, il existe un paramètre pour les tampons réseau). Je ne pense pas qu'il y ait une limite globale de 50%, bien qu'une limite globale soit quelque chose qui a été travaillé dans le but d'héberger des conteneurs.

Les pages basées sur des fichiers sont l'endroit où vous exécutez habituellement le code de l'espace utilisateur, vous avez donc besoin d'espace pour cela aussi.