La raison pour laquelle le OOM-killer n'est pas appelé automatiquement est que le système, bien qu'il soit complètement ralenti et ne réponde pas déjà lorsqu'il est presque à court de mémoire y, n'a pas réellement atteint la situation de mémoire insuffisante.
En simplifiant à l'extrême la ram presque pleine contient 3 types de données :
- les données du noyau, c'est essentiel
- des pages de données de processus essentielles (par exemple, toutes les données que le processus a créées en RAM uniquement)
- des pages de données de processus non essentielles (par exemple, des données telles que le code des exécutables, pour lesquelles il existe une copie sur le disque/dans le système de fichiers, et qui, tout en étant actuellement mappées sur la mémoire, pourraient être "relues" à partir du disque lors de l'utilisation )
Dans une situation de manque de mémoire, le noyau Linux, pour autant que je sache, est kswapd0 le thread du noyau, pour éviter la perte de données et la perte de fonctionnalités, ne peut pas jeter 1. et 2. , mais est libre de supprimer au moins temporairement ces données mappées dans les fichiers mémoire de la RAM qui forment des processus qui ne sont pas en cours d'exécution.
Bien qu'il s'agisse d'un comportement qui implique un vidage de disque, le fait de jeter constamment des données et de les relire à partir du disque peut être considéré comme utile car il évite, ou du moins reporte, la suppression/l'arrêt nécessaire d'un processus et la libération-mais-aussi- perdant sa mémoire, il a un high prix :performances.
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ]
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ]
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
coûte clairement IO cher et le système est susceptible de ne plus répondre, même si techniquement il n'est pas encore complètement épuisé de mémoire.
Du point de vue de l'utilisateur, cependant, il semble qu'il soit suspendu / gelé et que l'interface utilisateur qui ne réponde pas ne soit pas vraiment préférable, plutôt que de simplement tuer le processus (par exemple, d'un onglet de navigateur, dont l'utilisation de la mémoire aurait très bien pu être la cause première / le coupable de commencer.)
C'est là que, comme l'indiquait la question, le déclencheur de la touche Magic SysRq pour démarrer le MOO manuellement semble génial, car le Magic SysRq est moins impacté par l'absence de réponse du système.
Bien qu'il puisse y avoir des cas d'utilisation où il est important de préserver les processus (performances ) coûts, pour un ordinateur de bureau, il est probable que les utilisateurs préféreraient le tueur de MOO à l'interface utilisateur figée. Il existe un correctif qui prétend exempter les fichiers sauvegardés fs mappés propres de la mémoire dans une telle situation dans cette réponse sur stackoverflow.
Vous pouvez regarder le fichier /sys/fs/cgroup/memory/memory.oom_control, lors d'un stress test.
ou
Vous pouvez regarder sa date de dernière modification, pour voir si elle a été modifiée au moment du dernier blocage. Cela vous dira s'il tentait même de faire son travail.
under_oom 0
C'est votre problème :
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
S'il est défini sur 1, cela signifie qu'il est sous le contrôle de la pièce. Activé.
S'il est réglé sur 0, comme ça, il n'est pas sous le contrôle de la pièce. Désactivé.