Vous semblez ne pas comprendre le lien entre la mémoire virtuelle et l'overcommitting.
La mémoire physique est constituée des puces RAM de votre ordinateur. Il est physiquement impossible de utiliser plus de mémoire en même temps que vous avez de mémoire physique. Toutefois, depuis la fin des années 1970, il existe une mémoire virtuelle, dans laquelle le système déplace certaines données de la mémoire physique vers le disque, stockant ainsi la mémoire qui n'est pas réellement utilisée afin que la mémoire physique puisse être utilisée à d'autres fins. Lorsque cela se produit, les programmes ne peuvent pas utiliser immédiatement les données qui ont été déplacées ; lorsqu'ils essaient de le faire malgré tout, le processeur génère un défaut de page Le système d'exploitation doit alors charger les données requises dans la mémoire physique à partir de l'espace de pagination.
En utilisant la mémoire virtuelle, la quantité totale de données en vol qui peut être utilisée est étendue à la taille de la mémoire physique plus l'espace d'échange. Bien que cela permette au système d'exécuter plus de programmes en même temps, la quantité de mémoire virtuelle est plus importante que celle de la mémoire physique. en cours d'utilisation ne peut jamais dépasser le total des virtuel la mémoire (c'est-à-dire la RAM + l'espace d'échange)
En principe, le noyau devrait garder une trace de la quantité de mémoire que les programmes lui ont demandée, et il devrait rejeter les demandes de mémoire supplémentaire une fois que sa comptabilité lui indique que toute la mémoire a été utilisée. alloué même si elle ne l'a pas été en totalité utilisé . La plupart des autres noyaux le font, et n'ont donc pas d'OOM killer (parce qu'ils n'en ont pas besoin).
Cependant, l'appel système permettant à un programme d'allouer de la mémoire à partir du noyau n'alloue pas la mémoire par octets, mais par blocs plus importants. En revanche, l'implémentation réelle utilisée par la plupart des programmes pour obtenir de la mémoire (la fonction malloc() Fonction de la bibliothèque C) fait permettent aux programmes d'allouer de la mémoire par octet. Cela signifie que la plupart des programmes, lorsqu'ils demandent de la mémoire, obtiendront malloc() en allouant plus que ce dont ils ont réellement besoin. En outre, un bon malloc() utilisera certaines heuristiques pour séparer les petites et les grandes allocations, de sorte que la fragmentation de la mémoire ne soit pas trop importante, mais cela l'obligera à demander plus de mémoire au noyau, ce qui aggravera le problème. En raison de ces effets et d'autres, sans overcommitting, il y aura de grandes quantités de mémoire qui seront allouées mais qui ne seront pas utilisées. jamais à utiliser.
L'idée de l'overcommitting est que vous pouvez allouer en toute sécurité certains plus de mémoire que la quantité totale de mémoire virtuelle dont dispose votre système sans qu'il ne se mette en veilleuse. Essentiellement, le noyau prétend autoriser une allocation, même s'il n'est pas en mesure de le faire. sait il ne peut pas tenir cette promesse, en supposant qu'il n'aura pas besoin de tenir toute l'étendue de ces promesses. Cependant, il est impossible de prédire la quantité exacte qui peut être sur-engagée (allouée) sans que les choses ne tournent mal. Ainsi, lorsque le noyau détecte que des programmes essaient d'utiliser toute la mémoire qui leur a été allouée, il doit revenir sur ses promesses. C'est là qu'intervient l'OOM killer.
La question de savoir si c'est une bonne idée est à débattre. Lorsque le système n'a plus de mémoire, quelque chose va mal se passer. S'il s'agit d'une application qui tente de allouer de mémoire mais que le noyau a déjà tout réservé, il est possible que l'application en question se bloque. S'il s'agit de votre serveur X, vous n'avez pas de chance. Au moins, s'il y a un OOM killer, il peut décider quel processus tuer plutôt que les choses tournent mal après une mauvaise allocation ; et l'OOM killer a une certaine logique pour éviter de tuer des processus importants, comme votre serveur X...
Cependant, si vous préférez, il existe des boutons sysctl que vous pouvez utiliser pour désactiver l'overcommitting, si vous pensez que c'est une mauvaise idée.
