Ça peut.
Il existe deux conditions de mémoire insuffisantes que vous pouvez rencontrer sous Linux. Ce que vous rencontrez dépend de la valeur de sysctl vm.overcommit_memory
( /proc/sys/vm/overcommit_memory
)
Introduction:
Le noyau peut effectuer ce que l’on appelle «mémoire surchargée». C'est à ce moment que le noyau alloue aux programmes plus de mémoire que ce qui est réellement présent dans le système. Ceci est fait dans l'espoir que les programmes n'utiliseront pas réellement toute la mémoire allouée, car il s'agit d'un événement assez courant.
surcommit_memory = 2
Lorsque overcommit_memory
est défini sur 2
, le noyau n'effectue aucune surcharge. À la place, lorsqu'un programme se voit allouer de la mémoire, l'accès à cette mémoire est garanti. Si le système ne dispose pas de suffisamment de mémoire disponible pour satisfaire une demande d'allocation, le noyau renverra simplement un échec pour la demande. Il appartient au programme de gérer la situation avec élégance. S'il ne vérifie pas que l'allocation a réussi quand elle a réellement échoué, l'application rencontrera souvent un segfault.
Dans le cas du segfault, vous devriez trouver une ligne comme celle-ci dans la sortie de dmesg
:
[1962.987529] myapp[3303]: segfault at 0 ip 00400559 sp 5bc7b1b0 error 6 in myapp[400000+1000]
Les at 0
moyens que l'application a tenté d'accéder un pointeur non initialisé, ce qui peut être le résultat d'un appel d'allocation de mémoire a échoué (mais pas la seule).
surcommit_memory = 0 et 1
Lorsque l'option overcommit_memory
est définie sur 0
ou 1
, la surconsommation est activée et les programmes sont autorisés à allouer plus de mémoire que ce qui est réellement disponible.
Cependant, lorsqu'un programme souhaite utiliser la mémoire qui lui a été allouée, mais que le noyau s'aperçoit qu'il ne dispose pas de suffisamment de mémoire pour la satisfaire, il doit récupérer de la mémoire. Il essaie d’abord d’effectuer diverses tâches de nettoyage de la mémoire, telles que le vidage des caches, mais si cela ne suffit pas, il met fin au processus. Cette terminaison est effectuée par le MOO-Killer. OOM-Killer examine le système pour voir quels programmes utilisent quelle mémoire, depuis combien de temps ils fonctionnent, qui les utilise et un certain nombre d'autres facteurs permettant de déterminer celui qui sera tué.
Une fois le processus supprimé, la mémoire qu'il utilisait est libérée et le programme qui vient de provoquer la condition de mémoire insuffisante dispose désormais de la mémoire dont il a besoin.
Toutefois, même dans ce mode, les demandes d’allocation peuvent toujours être refusées aux programmes. Le cas overcommit_memory
échéant 0
, le noyau essaie de deviner quand il devrait commencer à refuser les demandes d'allocation. Lorsqu'il est défini sur 1
, je ne sais pas quelle détermination il utilise pour déterminer quand il doit refuser une demande, mais il peut refuser les demandes très volumineuses.
Vous pouvez voir si OOM-Killer est impliqué en examinant le résultat dmesg
et en recherchant des messages tels que:
[11686.043641] Out of memory: Kill process 2603 (flasherav) score 761 or sacrifice child
[11686.043647] Killed process 2603 (flasherav) total-vm:1498536kB, anon-rss:721784kB, file-rss:4228kB