OOM Killer tue des choses avec plein (?) De RAM libre

Le tueur OOM semble tuer des choses malgré avoir plus de RAM libre sur mon système:

Graphique d'utilisation de la mémoire (Résolution complète)

Graphique d'utilisation de l'OI (Résolution complète)

27 minutes et 408 process plus tard, le système a répondu à nouveau. Je l'ai redémarré environ une heure après, et bientôt l'utilisation de la memory est revenue à la normale (pour cette machine).

Lors de l'inspection, j'ai quelques process intéressants sur ma boîte:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [...snip...] root 1399 60702042 0.2 482288 1868 ? Sl Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4 [...snip...] mysql 2022 60730428 5.1 1606028 38760 ? Sl Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock [...snip...] 

Ce server spécifique est en cours d'exécution pour env. 8 heures, et ce sont les deux seuls process qui ont des … valeurs bizarres. Ma suspicion est que "quelque chose d'autre" se passe, potentiellement pertinent pour ces valeurs non sensibles. En particulier, je pense que le système pense qu'il ne manque pas de memory, en réalité, ce n'est pas le cas. Après tout, il pense que rsyslogd utilise systématiquement 55383984% de CPU, lorsque le maximum théorique est de 400% sur ce système de toute façon.

Il s'agit d'une installation entièrement embeddede CentOS 6 (6.2) avec 768 Mo de RAM. Des suggestions sur la façon de comprendre pourquoi cela se produit seront appréciées!

modifier: attacher le vm. sysctl tunables .. J'ai joué avec swappiness (rendu visible par 100), et je lance également un script absolument terrible qui décharge mes buffers et cache (mis en évidence par vm.drop_caches étant 3) + synchronise le disque tous les jours 15 minutes. C'est pourquoi, après le redémarrage, datatables mises en cache ont atteint une taille quelque peu normale, mais elles sont rapidement retombées. Je reconnais que le fait d'avoir un cache est une très bonne chose, mais jusqu'à ce que je sache ça …

Aussi un peu intéressant, c'est que pendant que mon file de page a augmenté au cours de l'événement, il n'a atteint que 20% de l'utilisation possible totale, ce qui n'est pas caractéristique des events OOM vrais. À l'autre extrémité du spectre, le disque s'est complètement coincé pendant la même période, ce qui est caractéristique d'un événement OOM lorsque le file de page est en jeu.

sysctl -a 2>/dev/null | grep '^vm' sysctl -a 2>/dev/null | grep '^vm' :

 vm.overcommit_memory = 1 vm.panic_on_oom = 0 vm.oom_kill_allocating_task = 0 vm.extfrag_threshold = 500 vm.oom_dump_tasks = 0 vm.would_have_oomkilled = 0 vm.overcommit_ratio = 50 vm.page-cluster = 3 vm.dirty_background_ratio = 10 vm.dirty_background_bytes = 0 vm.dirty_ratio = 20 vm.dirty_bytes = 0 vm.dirty_writeback_centisecs = 500 vm.dirty_expire_centisecs = 3000 vm.nr_pdflush_threads = 0 vm.swappiness = 100 vm.nr_hugepages = 0 vm.hugetlb_shm_group = 0 vm.hugepages_treat_as_movable = 0 vm.nr_overcommit_hugepages = 0 vm.lowmem_reserve_ratio = 256 256 32 vm.drop_caches = 3 vm.min_free_kbytes = 3518 vm.percpu_pagelist_fraction = 0 vm.max_map_count = 65530 vm.laptop_mode = 0 vm.block_dump = 0 vm.vfs_cache_pressure = 100 vm.legacy_va_layout = 0 vm.zone_reclaim_mode = 0 vm.min_unmapped_ratio = 1 vm.min_slab_ratio = 5 vm.stat_interval = 1 vm.mmap_min_addr = 4096 vm.numa_zonelist_order = default vm.scan_unevictable_pages = 0 vm.memory_failure_early_kill = 0 vm.memory_failure_recovery = 1 

éditer: et joindre le premier message OOM … lors d'une inspection plus approfondie, il dit que quelque chose a bien évidemment fait tout son possible pour manger l'intégralité de mon espace de swap.

 Feb 21 17:12:49 host kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0 Feb 21 17:12:51 host kernel: mysqld cpuset=/ mems_allowed=0 Feb 21 17:12:51 host kernel: Pid: 2777, comm: mysqld Not tainted 2.6.32-71.29.1.el6.x86_64 #1 Feb 21 17:12:51 host kernel: Call Trace: Feb 21 17:12:51 host kernel: [<ffffffff810c2e01>] ? cpuset_print_task_mems_allowed+0x91/0xb0 Feb 21 17:12:51 host kernel: [<ffffffff8110f1bb>] oom_kill_process+0xcb/0x2e0 Feb 21 17:12:51 host kernel: [<ffffffff8110f780>] ? select_bad_process+0xd0/0x110 Feb 21 17:12:51 host kernel: [<ffffffff8110f818>] __out_of_memory+0x58/0xc0 Feb 21 17:12:51 host kernel: [<ffffffff8110fa19>] out_of_memory+0x199/0x210 Feb 21 17:12:51 host kernel: [<ffffffff8111ebe2>] __alloc_pages_nodemask+0x832/0x850 Feb 21 17:12:51 host kernel: [<ffffffff81150cba>] alloc_pages_current+0x9a/0x100 Feb 21 17:12:51 host kernel: [<ffffffff8110c617>] __page_cache_alloc+0x87/0x90 Feb 21 17:12:51 host kernel: [<ffffffff8112136b>] __do_page_cache_readahead+0xdb/0x210 Feb 21 17:12:51 host kernel: [<ffffffff811214c1>] ra_submit+0x21/0x30 Feb 21 17:12:51 host kernel: [<ffffffff8110e1c1>] filemap_fault+0x4b1/0x510 Feb 21 17:12:51 host kernel: [<ffffffff81135604>] __do_fault+0x54/0x500 Feb 21 17:12:51 host kernel: [<ffffffff81135ba7>] handle_pte_fault+0xf7/0xad0 Feb 21 17:12:51 host kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0 Feb 21 17:12:51 host kernel: [<ffffffff8100f951>] ? xen_clocksource_read+0x21/0x30 Feb 21 17:12:51 host kernel: [<ffffffff8100fa39>] ? xen_clocksource_get_cycles+0x9/0x10 Feb 21 17:12:51 host kernel: [<ffffffff8100c949>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e Feb 21 17:12:51 host kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0 Feb 21 17:12:51 host kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0 Feb 21 17:12:51 host kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30 Feb 21 17:12:51 host kernel: Mem-Info: Feb 21 17:12:51 host kernel: Node 0 DMA per-cpu: Feb 21 17:12:51 host kernel: CPU 0: hi: 0, btch: 1 usd: 0 Feb 21 17:12:51 host kernel: CPU 1: hi: 0, btch: 1 usd: 0 Feb 21 17:12:51 host kernel: CPU 2: hi: 0, btch: 1 usd: 0 Feb 21 17:12:51 host kernel: CPU 3: hi: 0, btch: 1 usd: 0 Feb 21 17:12:51 host kernel: Node 0 DMA32 per-cpu: Feb 21 17:12:51 host kernel: CPU 0: hi: 186, btch: 31 usd: 47 Feb 21 17:12:51 host kernel: CPU 1: hi: 186, btch: 31 usd: 0 Feb 21 17:12:51 host kernel: CPU 2: hi: 186, btch: 31 usd: 0 Feb 21 17:12:51 host kernel: CPU 3: hi: 186, btch: 31 usd: 174 Feb 21 17:12:51 host kernel: active_anon:74201 inactive_anon:74249 isolated_anon:0 Feb 21 17:12:51 host kernel: active_file:120 inactive_file:276 isolated_file:0 Feb 21 17:12:51 host kernel: unevictable:0 dirty:0 writeback:2 unstable:0 Feb 21 17:12:51 host kernel: free:1600 slab_reclaimable:2713 slab_unreclaimable:19139 Feb 21 17:12:51 host kernel: mapped:177 shmem:84 pagetables:12939 bounce:0 Feb 21 17:12:51 host kernel: Node 0 DMA free:3024kB min:64kB low:80kB high:96kB active_anon:5384kB inactive_anon:5460kB active_file:36kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14368kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:116kB kernel_stack:32kB pagetables:140kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 741 741 741 Feb 21 17:12:51 host kernel: Node 0 DMA32 free:3376kB min:3448kB low:4308kB high:5172kB active_anon:291420kB inactive_anon:291536kB active_file:444kB inactive_file:1092kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:759520kB mlocked:0kB dirty:0kB writeback:8kB mapped:692kB shmem:336kB slab_reclaimable:10836kB slab_unreclaimable:76440kB kernel_stack:2520kB pagetables:51616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2560 all_unreclaimable? yes Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 0 0 0 Feb 21 17:12:51 host kernel: Node 0 DMA: 5*4kB 4*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3028kB Feb 21 17:12:51 host kernel: Node 0 DMA32: 191*4kB 63*8kB 9*16kB 2*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3396kB Feb 21 17:12:51 host kernel: 4685 total pagecache pages Feb 21 17:12:51 host kernel: 4131 pages in swap cache Feb 21 17:12:51 host kernel: Swap cache stats: add 166650, delete 162519, find 1524867/1527901 Feb 21 17:12:51 host kernel: Free swap = 0kB Feb 21 17:12:51 host kernel: Total swap = 523256kB Feb 21 17:12:51 host kernel: 196607 pages RAM Feb 21 17:12:51 host kernel: 6737 pages reserved Feb 21 17:12:51 host kernel: 33612 pages shared Feb 21 17:12:51 host kernel: 180803 pages non-shared Feb 21 17:12:51 host kernel: Out of memory: kill process 2053 (mysqld_safe) score 891049 or a child Feb 21 17:12:51 host kernel: Killed process 2266 (mysqld) vsz:1540232kB, anon-rss:4692kB, file-rss:128kB 

3 Solutions collect form web for “OOM Killer tue des choses avec plein (?) De RAM libre”

Je viens de regarder le vaisseau de bit oom, et je doute de l'exactitude de ce graphique. Notez la première ligne 'Node 0 DMA32'. Il dit free:3376kB , min:3448kB , et low:4308kB . Chaque fois que la valeur libre descend en dessous de la valeur basse, kswapd est censé commencer à échanger des choses jusqu'à ce que cette valeur remonte au-dessus de la valeur élevée. Chaque fois que les gouttes libres sont inférieures à min., Le système gèle essentiellement jusqu'à ce que le kernel le remonte au-dessus de la valeur min. Ce message indique également que le swap a été complètement utilisé lorsqu'il indique Free swap = 0kB .
Donc, fondamentalement, kswapd a déclenché, mais le swap était plein, donc il ne pouvait rien faire, et la valeur de pages_free était toujours inférieure à la valeur pages_min, donc la seule option était de commencer à tuer les choses jusqu'à ce qu'il puisse récupérer les pages sans sauvegarde.
Vous avez définitivement manqué de memory.

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html a une très bonne explication de la façon dont cela fonctionne. Voir la section «Mise en œuvre» en bas.

Débarrassez-vous du script drop_caches. En outre, vous devez publier les parties pertinentes de votre sortie dmesg et /var/log/messages affichant les messages OOM.

Pour arrêter ce comportement, cependant, je reorderais d'essayer ce sysctl accordable. Il s'agit d'un système RHEL / CentOS 6 et fonctionne clairement avec des ressources contraintes. Est-ce une machine virtuelle?

Essayez de modifier /proc/sys/vm/nr_hugepages et de voir si les problèmes persistent. Cela pourrait être un problème de fragmentation de memory, mais voyez si ce paramètre fait la différence. Pour rendre le changement permanent, ajoutez vm.nr_hugepages = value à votre /etc/sysctl.conf et exécutez sysctl -p pour relire le file de configuration …

Voir aussi: Interprétation des messages "échec d'allocation de page" du kernel cryptique

Il n'y a aucune donnée disponible sur le graphique à partir du moment où le tueur OOM commence jusqu'à ce qu'il se termine. Je crois en l'intervalle temporel où le graphique est interrompu qu'en fait, la consommation de memory augmente et il n'y a plus de memory disponible. Sinon, le tueur OOM ne serait pas utilisé. Si vous regardez le graphe de la memory libre après que le tueur OOM s'est arrêté, vous pouvez le voir diminuer d'une valeur supérieure à celle antérieure. Au less, il a fait son travail correctement, libérant de la memory.

Notez que votre espace de swap est presque utilisé complètement jusqu'à redémarrer. C'est presque jamais une bonne chose et un signe sûr, il rest peu de memory libre.

La raison pour laquelle il n'y a pas de données disponibles pour ce timeout particulier est que le système est trop occupé avec d'autres choses. Les valeurs «drôles» dans votre list de process peuvent être un résultat et non une cause. Ce n'est pas inconnu.

Vérifiez /var/log/kern.log et / var / log / messages, quelles informations pouvez-vous find là-bas?

Si la journalisation a également été arrêtée, essayez d'autres choses, déchargez la list des process vers un file chaque seconde environ, ce qui correspond aux informations de performance du système. Exécutez-le avec une priorité élevée afin qu'il puisse encore faire son travail (espérons-le) lorsque les pointes de charge. Bien que si vous ne possédez pas un kernel de préemption (parfois indiqué comme un «kernel de server»), vous pouvez avoir de la chance à cet égard.

Je pense que vous constaterez que le (s) process (s) qui utilisent le plus de CPU% autour du moment où vos problèmes commencent sont (sont) la cause. Je n'ai jamais vu rsyslogd ni mysql se comporter de cette façon. Les causes les plus susceptibles sont les applications java et les applications guidées par gui, comme un browser.

  • Rsync a déclenché Linux OOM killer sur un seul file de 50 Go
  • OOM Killer devient fou
  • Ajustement des notes OOM
  • OOM-Killer, jboss et kernel panique
  • Android java build drained 8GB de memory
  • Analyse judiciaire du OOM-Killer
  • Redis mange de plus en plus de mémoire
  • Comment existe-t-il jamais un scénario OOM sur Linux (heuristique derrière OOM Killer)?
  • Comment savoir quel cgroup a provoqué OOM?
  • Comment obtenir le tueur Linux OOM pour ne pas tuer mon processus?
  • OOM malgré la mémoire disponible (cache)
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.