Où va la memory restante de vm.overcommit_ratio?

Si je désactive le vm.overcommit_memory de la memory en définissant vm.overcommit_memory sur 2 , le système autorisera par défaut l'allocation de la memory à la taille du swap + 50% de la memory physique, comme expliqué ici .

Je peux changer le ratio en modifiant le paramètre vm.overcommit_ratio . Disons que je le règle à 80%, donc 80% de la memory physique peut être utilisée.

Ma question est la suivante:

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

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

Le kernel utilisera la memory physique restante pour ses propres besoins (structures internes, tables, tampons, caches, etc.). Le paramètre de surcapacité de memory gère les réservations de memory virtuelle de l'application userland, le kernel n'utilise pas de memory virtuelle mais physique.

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

Le paramètre overcommit_ratio est un choix d'implémentation conçu pour empêcher les applications de réserver plus de memory virtuelle que ce qui leur sera raisonnablement disponible à l'avenir, c'est-à-dire lorsqu'elles accèdent effectivement à la memory.

Le paramètre overcommit_ratio à 50% a été considéré comme une valeur par défaut raisonnable par les développeurs du kernel Linux. Il suppose que le kernel n'aura jamais besoin d'utiliser plus de 50% de la RAM physique. Votre kilométrage peut varier, la raison pour laquelle c'est un accordable.

Pourquoi je ne devrais pas toujours le fixer à 100%?

Le paramétrer à 100% (ou toute valeur "trop ​​élevée") ne permet pas de désactiver de manière fiable le surcoût car vous ne pouvez pas supposer que le kernel utilise 0% (ou trop peu) de RAM.

Cela n'empêchera pas les applications de se bloquer, car le kernel pourrait, de toute façon, anticiper toute la memory physique requirejse.

Si vous définissez le ratio à 100%, vous ne réserverez pas d'espace aux pages sauvegardées par file ou aux allocations dans le kernel telles que le code du kernel, les tampons réseau, etc.

Les structures dans le kernel seront allouées indépendamment, provoquant un overcommit. 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 p. 100, même si une limite globale a été utilisée pour héberger des conteneurs.

L'utilisation principale des pages sauvegardées par file consiste à exécuter du code d'espace user, donc vous avez besoin d'espace pour cela aussi.