Le tueur OOM semble tuer des choses malgré qu'il y ait plus qu'assez de RAM libre sur mon système:
27 minutes et 408 processus plus tard, le système a recommencé à répondre. Je l'ai redémarré environ une heure après, et peu après, l'utilisation de la mémoire est revenue à la normale (pour cette machine).
Après inspection, j'ai quelques processus intéressants en cours d'exécution 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 serveur spécifique fonctionne depuis env. 8 heures, et ce sont les deux seuls processus qui ont des valeurs aussi ... étranges. Je soupçonne qu'il se passe "quelque chose d'autre", potentiellement pertinent pour ces valeurs non sensorielles. Plus précisément, je pense que le système pense qu'il est hors de mémoire, alors qu'en réalité ce n'est pas le cas. Après tout, il pense que rsyslogd utilise un processeur 55383984% de manière cohérente, alors que le maximum théorique est de 400% sur ce système de toute façon.
Il s'agit d'une installation CentOS 6 entièrement mise à jour (6.2) avec 768 Mo de RAM. Toute suggestion sur la façon de comprendre pourquoi cela se produit serait appréciée!
modifier: attacher le vm. sysctl tunables .. J'ai joué avec swappiness (rendu évident par le fait qu'il soit 100), et je lance également un script absolument terrible qui vide mes tampons et cache (rendu évident par vm.drop_caches étant 3) + synchronise le disque chaque 15 minutes. C'est pourquoi après le redémarrage, les données mises en cache ont atteint une taille quelque peu normale, mais ont ensuite rapidement chuté à nouveau. Je reconnais qu'avoir du cache est une très bonne chose, mais jusqu'à ce que je comprenne cela ...
Il est également intéressant de noter que bien que mon fichier d'échange ait augmenté pendant l'événement, il n'a atteint que 20% de l'utilisation totale possible, ce qui n'est pas caractéristique des événements OOM réels. À l'autre extrémité du spectre, le disque est devenu complètement fou pendant la même période, ce qui est caractéristique d'un événement MOO lorsque le fichier d'échange est en cours de lecture.
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
edit: et en joignant le premier message OOM ... en y regardant de plus près, cela signifie que quelque chose s'est clairement mis en travers pour manger l'intégralité de mon espace de swap également.
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
sysctl -a 2>/dev/null | grep '^vm'?overcommit_memorydécor. Le mettre à 1 ne devrait pas provoquer ce problème, mais je n'ai jamais eu besoin de le régler sur «toujours sur-engagé» auparavant, donc pas beaucoup d'expérience là-bas. En regardant les autres notes que vous avez ajoutées, vous avez dit que le swap n'était utilisé qu'à 20%. Toutefois , selon la sauvegarde du journal de OOM,Free swap = 0kB. Il pensait certainement que le swap était utilisé à 100%.Réponses:
Je viens de regarder le vidage du journal oom, et je doute de l'exactitude de ce graphique. Remarquez la première ligne «Node 0 DMA32». Il dit
free:3376kB,min:3448kBetlow:4308kB. Chaque fois que la valeur libre tombe en dessous de la valeur basse, kswapd est censé commencer à échanger des choses jusqu'à ce que cette valeur remonte au-dessus de la valeur haute. Chaque fois que free tombe en dessous de min, le système se fige essentiellement jusqu'à ce que le noyau le récupère au-dessus de la valeur min. Ce message indique également que l'échange a été complètement utilisé là où il est indiquéFree swap = 0kB.Donc, fondamentalement, kswapd s'est déclenché, mais le swap était complet, donc il ne pouvait rien faire, et la valeur pages_free était toujours inférieure à la valeur pages_min, donc la seule option était de commencer à tuer des choses jusqu'à ce qu'il puisse récupérer pages_free.
Vous avez définitivement manqué de mémoire.
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 «Implémentation» en bas.
la source
Débarrassez-vous du script drop_caches. En outre, vous devez publier les parties pertinentes de votre sortie
dmesget/var/log/messagesafficher les messages MOO.Pour arrêter ce comportement, je vous recommande d'essayer ce
sysctlparamètre. Il s'agit d'un système RHEL / CentOS 6 et fonctionne clairement sur des ressources limitées. Est-ce une machine virtuelle?Essayez de modifier
/proc/sys/vm/nr_hugepageset voyez si les problèmes persistent. Cela pourrait être un problème de fragmentation de la mémoire, mais voyez si ce paramètre fait une différence. Pour rendre le changement permanent, ajoutez-vm.nr_hugepages = valuele/etc/sysctl.confet lancezsysctl -ppour relire le fichier de configuration ...Voir aussi: Interprétation des messages "échec d'allocation de page" du noyau cryptique
la source
Il n'y a aucune donnée disponible sur le graphique depuis le début du tueur OOM jusqu'à sa fin. Je crois dans l'intervalle de temps où le graphique est interrompu qu'en fait la consommation de mémoire augmente et qu'il n'y a plus de mémoire disponible. Sinon, le tueur OOM ne serait pas utilisé. Si vous regardez le graphique de mémoire libre après l'arrêt du tueur OOM, vous pouvez voir qu'il descend d'une valeur plus élevée qu'auparavant. Au moins, il a fait son travail correctement, libérant de la mémoire.
Notez que votre espace d'échange est presque entièrement utilisé jusqu'au redémarrage. Ce n'est presque jamais une bonne chose et un signe certain qu'il reste peu de mémoire libre.
La raison pour laquelle il n'y a pas de données disponibles pour cette période particulière est que le système est trop occupé par d'autres choses. Les valeurs "drôles" dans votre liste de processus peuvent être simplement un résultat, pas une cause. Ce n'est pas inconnu.
Vérifiez /var/log/kern.log et / var / log / messages, quelles informations pouvez-vous y trouver?
Si la journalisation s'est également arrêtée, essayez d'autres choses, videz la liste des processus dans un fichier toutes les secondes environ, de même avec les informations sur les performances du système. Exécutez-le avec une priorité élevée afin qu'il puisse toujours faire son travail (espérons-le) lorsque la charge augmente. Bien que si vous n'avez pas de noyau préemptif (parfois indiqué comme noyau "serveur"), vous risquez de manquer de chance à cet égard.
Je pense que vous constaterez que le (s) processus qui utilise (nt) le plus de CPU% au 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 coupables les plus probables sont les applications java et les applications gui comme un navigateur.
la source