Para verificar os 20 maiores consumidores de memória física (tamanho do conjunto de residentes).
crash> ps -G | sed 's/>//g' | sort -k 8,8 -n | awk '$8 ~ /[0-9]/{ $8 = $8/1024" MB"; print }' | tail -20
Para verificar o número de páginas de entrada.
crash> p -d nr_huge_pages
Atualização:
A) o despejo de memória foi capturado da seguinte versão do kernel.
$ crash --osrelease vmcore.flat
2.6.32-279.5.2.el6.x86_64
B) Vamos extrair o arquivo vmlinux do pacote kernel-debug-debuginfo.
$ rpm2cpio kernel-debug-debuginfo-2.6.32-279.5.2.el6.x86_64.rpm | \
cpio -idv ./usr/lib/debug/lib/modules/*/vmlinux
C) Abra o arquivo vmcore usando o utilitário de falha.
$ bunzip2 vmcore.flat.bz2
$ crash vmcore.flat ./usr/lib/debug/lib/modules/2.6.32-279.5.2.el6.x86_64/vmlinux
D) Informação do sistema.
crash> sys
KERNEL: ./usr/lib/debug/lib/modules/2.6.32-279.5.2.el6.x86_64/vmlinux
DUMPFILE: vmcore.flat [PARTIAL DUMP]
CPUS: 32
DATE: Tue Feb 5 12:11:52 2013
UPTIME: 00:04:12
LOAD AVERAGE: 3.03, 0.95, 0.34
TASKS: 578
NODENAME: ...
RELEASE: 2.6.32-279.5.2.el6.x86_64
VERSION: #1 SMP Fri Aug 24 01:07:11 UTC 2012
MACHINE: x86_64 (2700 Mhz)
MEMORY: 64 GB
PANIC: "[ 253.529344] Kernel panic - not syncing: Out of memory and no killable processes..."
a) O pânico aconteceu devido a falta de memória, mas o parâmetro "panic_on_oom" está desativado no sistema.
crash> p -d sysctl_panic_on_oom
sysctl_panic_on_oom = $6 = 0
Este parâmetro habilita ou desabilita o recurso de falta de memória do pânico. Se isto estiver configurado para 0, o kernel irá matar algum processo invasor, chamado oom_killer. Normalmente, o oom_killer pode matar processos desonestos e o sistema sobreviverá. Se isso for definido como 1, o kernel entra em pane quando a falta de memória acontece.
b) Então, como capturamos o vmcore no momento do evento?
Bem, vamos verificar o código-fonte mm / oom_kill.c. Ele diz que, se nada for deixado no sistema para matar, simplesmente pendure ou entre em pânico.
++++++
499 /* Found nothing?!?! Either we hang forever, or we panic. */
500 if (!p) {
501 read_unlock(&tasklist_lock);
502 cpuset_unlock();
503 panic("Out of memory and no killable processes...\n"); <<<------
504 }
505
++++++
Então chegamos ao estado de pânico e como o serviço kdump foi ativado neste sistema, o vmcore foi capturado.
E) Permite verificar o buffer de anel do kernel,
crash> log
[..]
[ 253.351427] Node 0 DMA free:15744kB min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15356kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 253.352234] lowmem_reserve[]: 0 2955 32245 32245
[ 253.352812] Node 0 DMA32 free:120436kB min:4120kB low:5148kB high:6180kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3026080kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:20kB slab_unreclaimable:16600kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no
[ 253.353637] lowmem_reserve[]: 0 0 29290 29290
[ 253.354216] Node 0 Normal free:40580kB min:40868kB low:51084kB high:61300kB active_anon:956kB inactive_anon:536kB active_file:260kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:29992960kB mlocked:0kB dirty:0kB writeback:0kB mapped:460kB shmem:136kB slab_reclaimable:3640kB slab_unreclaimable:75128kB kernel_stack:4448kB pagetables:428kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 253.355047] lowmem_reserve[]: 0 0 0 0
[ 253.355624] Node 1 Normal free:39896kB min:45096kB low:56368kB high:67644kB active_anon:412kB inactive_anon:1668kB active_file:288kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):220kB present:33095680kB mlocked:0kB dirty:0kB writeback:0kB mapped:92kB shmem:80kB slab_reclaimable:3496kB slab_unreclaimable:87864kB kernel_stack:216kB pagetables:564kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 253.356457] lowmem_reserve[]: 0 0 0 0
[ 253.357034] Node 0 DMA: 2*4kB 1*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15744kB
[ 253.358351] Node 0 DMA32: 41*4kB 8*8kB 7*16kB 6*32kB 10*64kB 10*128kB 7*256kB 9*512kB 7*1024kB 5*2048kB 23*4096kB = 120468kB
[ 253.359674] Node 0 Normal: 718*4kB 558*8kB 278*16kB 169*32kB 88*64kB 47*128kB 13*256kB 5*512kB 0*1024kB 1*2048kB 1*4096kB = 40872kB
[ 253.360995] Node 1 Normal: 876*4kB 447*8kB 249*16kB 174*32kB 116*64kB 40*128kB 8*256kB 1*512kB 1*1024kB 2*2048kB 1*4096kB = 40952kB
[ 253.362319] 154 total pagecache pages
[ 253.362502] 0 pages in swap cache
[ 253.362684] Swap cache stats: add 0, delete 0, find 0/0
[ 253.362869] Free swap = 0kB
[ 253.363050] Total swap = 0kB
[ 253.526814] 16777215 pages RAM
[ 253.526999] 294628 pages reserved
[ 253.527190] 114911 pages shared
[ 253.527372] 16392561 pages non-shared
[..]
F) Permite verificar o status da memória no sistema no momento da falha.
crash> kmem -i
PAGES TOTAL PERCENTAGE
TOTAL MEM 16482587 62.9 GB ---- -------------------------------+
FREE 54610 213.3 MB 0% of TOTAL MEM |
USED 16427977 62.7 GB 99% of TOTAL MEM |
SHARED 4683 18.3 MB 0% of TOTAL MEM |
BUFFERS 118 472 KB 0% of TOTAL MEM |
CACHED 82 328 KB 0% of TOTAL MEM |
SLAB 46635 182.2 MB 0% of TOTAL MEM |
|
TOTAL SWAP 0 0 ---- ----------------------+ |
SWAP USED 0 0 100% of TOTAL SWAP | |
SWAP FREE 0 0 0% of TOTAL SWAP | |
| |
| |
crash> p -d totalram_pages | |
totalram_pages = $5 = 16482587 | |
| |
crash> !echo "scale=5;(16482587*4096)/2^30"|bc -q | |
62.87607 <<<-----[ Total physical memory is 62.9 GB ] <<<--|--------+
|
crash> p -d total_swap_pages |
total_swap_pages = $6 = 0 <<<------[ No Swap on the system ] <<<-----------+
- Temos um total de 63GiB de memória física.
- A partição ou arquivo de swap não é criado no sistema, portanto, não temos swap neste servidor.
- A memória usada para cache é muito menor que 328KB e para buffer é de 472KB.
- A memória usada na laje também é muito menos apenas 182,2 MB.
G) A memória total alocada para o (s) processo (s) é de 0,00391006GiB.
crash> ps -G | tail -n +2 | cut -b2- | gawk '{mem += $8} END {print "total " mem/1048576 "GB"}'
total 0.00391006GB
H) O (s) processo (s) de aplicação não está utilizando memória no sistema.
crash> ps -G | sed 's/>//g' | sort -k 8,8 -n | awk '$8 ~ /[0-9]/{ $8 = $8/1024" MB"; print }' | tail -20
965 2 21 ffff8808292f1500 IN 0.0 0 0 MB [ext4-dio-unwrit]
966 2 22 ffff8808292d4080 IN 0.0 0 0 MB [ext4-dio-unwrit]
967 2 23 ffff8808292ce040 IN 0.0 0 0 MB [ext4-dio-unwrit]
968 2 24 ffff8808299b5540 IN 0.0 0 0 MB [ext4-dio-unwrit]
969 2 25 ffff880829aa6040 IN 0.0 0 0 MB [ext4-dio-unwrit]
970 2 26 ffff880827367500 IN 0.0 0 0 MB [ext4-dio-unwrit]
971 2 27 ffff880827366aa0 IN 0.0 0 0 MB [ext4-dio-unwrit]
972 2 28 ffff880827366040 IN 0.0 0 0 MB [ext4-dio-unwrit]
97 2 23 ffff88082c1ac080 IN 0.0 0 0 MB [ksoftirqd/23]
973 2 29 ffff880827371540 IN 0.0 0 0 MB [ext4-dio-unwrit]
974 2 30 ffff880827370ae0 IN 0.0 0 0 MB [ext4-dio-unwrit]
975 2 31 ffff880827370080 IN 0.0 0 0 MB [ext4-dio-unwrit]
98 2 23 ffff88082c1bb500 IN 0.0 0 0 MB [watchdog/23]
99 2 24 ffff88082c1baaa0 IN 0.0 0 0 MB [migration/24]
3171 1 3 ffff880826ccaaa0 IN 0.0 27636 0.234375 MB auditd
1 0 1 ffff88082c41b500 UN 0.0 19348 0.339844 MB init
3772 1 0 ffff88102b257500 RU 0.0 64072 0.652344 MB sshd
1047 1 2 ffff881029524040 IN 0.0 11188 0.925781 MB udevd
4936 1047 4 ffff880ff342d540 IN 0.0 11184 0.925781 MB udevd
4937 1047 5 ffff88082a240080 IN 0.0 11184 0.925781 MB udevd
I) Vamos verificar os parâmetros de ajuste de memória no sistema.
crash> p -d sysctl_overcommit_memory
sysctl_overcommit_memory = $7 = 0
Esse valor contém um sinalizador que permite o comprometimento excessivo de memória. Quando este sinalizador é 0, o kernel tenta estimar a quantidade de memória livre deixada quando o espaço do usuário solicita mais memória.
crash> p -d sysctl_overcommit_ratio
sysctl_overcommit_ratio = $8 = 50
Quando overcommit_memory é definido como 2, o espaço de endereço confirmado não pode exceder o swap além dessa porcentagem de RAM física.
crash> p -d zone_reclaim_mode
zone_reclaim_mode = $4 = 0
Zone_reclaim_mode permite que alguém defina abordagens mais ou menos agressivas para recuperar memória quando uma zona fica sem memória. Se estiver definido para zero, não ocorrerá recuperação de zona.
crash> p -d min_free_kbytes
min_free_kbytes = $3 = 90112 <<<--------[ 88 MB ]
O número mínimo de kilobytes para manter livre em todo o sistema. Esse valor é usado para calcular um valor de marca d'água para cada zona de pouca memória, que recebe um número de páginas livres reservadas proporcionalmente ao seu tamanho. Ao definir este parâmetro, os valores muito baixos e muito altos podem ser prejudiciais.
Em outras palavras, definir min_free_kbytes too low evita que o sistema recupere memória. Isso pode resultar em interrupções do sistema e matando vários processos pelo OOM. No entanto, definir esse parâmetro para um valor muito alto (5 a 10% da memória total do sistema) fará com que o sistema fique fora de memória imediatamente. O Linux foi projetado para usar toda a RAM disponível para armazenar em cache os dados do sistema de arquivos. Definir um valor alto min_free_kbytes resulta no sistema gastando muito tempo recuperando memória.
Os valores dos parâmetros acima parecem bem, Então, onde está minha memória ???
Suposições:
- O principal ofensor não está no espaço do usuário. Com base na minha experiência, a memória inexplicável é devido aos módulos Mellanox e DRBD, mas não tenho certeza no seu caso.
- Como a maioria das páginas são descartadas do arquivo vmcore para reduzir o tamanho do arquivo vmcore (core_collector makedumpfile -d 31 -c). Não consigo verificar o tamanho da página de tamanho.