Situação oom do Linux (kernel de 32 bits)

Question 1

Uma abordagem de 'marreta' seria atualizar para um sistema operacional de 64 bits (isto é 32 bits) porque o layout das zonas é feito de forma diferente.

OK, então aqui tentarei responder por que você experimentou um OOM aqui. Há uma série de fatores em jogo aqui.

O tamanho do pedido da solicitação e como o kernel trata determinados tamanhos de pedido.
A zona que está sendo selecionada.
As marcas d'água que esta zona usa.
Fragmentação na zona.

Se você olhar para o próprio OOM, há claramente muita memória livre disponível, mas o OOM-killer foi invocado? Por que?

O tamanho do pedido da solicitação e como o kernel trata determinados tamanhos de pedido

O kernel aloca memória por ordem. Um 'pedido' é uma região de RAM contígua que deve ser atendida para que a solicitação funcione. Os pedidos são organizados por ordens de magnitude (daí o nome ordem) usando o algoritmo 2^(ORDER + 12). Portanto, a ordem 0 é 4.096, a ordem 1 é 8.192, a ordem 2 é 16.384 e assim por diante.

O kernel possui um valor codificado do que é considerado uma 'ordem superior' (> PAGE_ALLOC_COSTLY_ORDER). Esta é a ordem 4 e superior (64kb ou superior é uma ordem superior).

Os pedidos mais altos são atendidos para alocações de páginas de maneira diferente dos pedidos mais baixos. Uma alocação de alta ordem se não conseguir capturar a memória, nos kernels modernos o fará.

Tente executar a rotina de compactação de memória para desfragmentar a memória.
Nuncachame o OOM-killer para atender à solicitação.

O tamanho do seu pedido está listado aqui

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

A ordem 3 é a mais alta das solicitações de ordem inferior e (como você pode ver) invoca o OOM-killer na tentativa de satisfazê-la.

Observe que a maioria das alocações de espaço de usuário não usa solicitações de ordem superior. Normalmente é o kernel que requer regiões contíguas de memória. Uma exceção a isso pode ser quando o espaço do usuário está usando páginas enormes - mas esse não é o caso aqui.

No seu caso, a alocação de ordem 3 é chamada pelo kernel que deseja enfileirar um pacote na pilha de rede - exigindo uma alocação de 32kb para fazer isso.

A zona que está sendo selecionada.

O kernel divide suas regiões de memória em zonas. Essa divisão é feita porque no x86 certas regiões da memória só são endereçáveis por determinados hardwares. Hardware mais antigo só pode endereçar memória na zona 'DMA', por exemplo. Quando queremos alocar alguma memória, primeiro uma zona é escolhida eapenasa memória livre desta zona é contabilizada ao tomar uma decisão de alocação.

Embora eu não tenha conhecimento total do algoritmo de seleção de zona, o caso de uso típico nunca é alocar do DMA, mas geralmente selecionar a zona endereçável mais baixa que possa satisfazer a solicitação.

Muitas informações de zona são divulgadas durante o OOM, que também podem ser obtidas em /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

As zonas que você possui, DMA, Normal e HighMem indicam uma plataforma de 32 bits, pois a zona HighMem é inexistente em 64 bits. Também em sistemas de 64 bits, o Normal é mapeado para 4 GB e além, enquanto em 32 bits ele mapeia até 896 MB (embora, no seu caso, o kernel relate apenas o gerenciamento de uma parte menor do que esta: - managed:587540kB.)

É possível saber de onde veio essa alocação olhando novamente a primeira linha, gfp_mask=0x42d0que nos diz que tipo de alocação foi feita. O último byte (0) nos diz que esta é uma alocação da zona normal. Os significados do gfp estão localizados eminclude/linux/gfp.h.

As marcas d'água que esta zona usa.

Quando a memória está baixa, as ações para recuperá-la são especificadas pela marca d’água. Eles aparecem aqui: min:3044kB low:3804kB high:4564kB. Se a memória livre atingir o nível 'baixo', a troca ocorrerá até ultrapassarmos o limite 'alto'. Se a memória atingir 'min', precisamos eliminar coisas para liberar memória por meio do OOM-killer.

Fragmentação na zona.

Para verificar se uma solicitação para uma ordem específica de memória pode ser atendida, o kernel contabiliza quantas páginas livres e disponíveis de cada ordem. Isso pode ser lido em /proc/buddyinfo. Os relatórios do OOM-killer também revelam as informações do amigo, conforme visto aqui:

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

Para que uma alocação de memória seja satisfeita, hádevehaver memória livre disponível no tamanho do pedido solicitado ou em uma alocação superior. Ter muitos dados livres nas ordens inferiores e nenhum nas ordens superiores significa que sua memória está fragmentada. Se você obtiver uma alocação de pedidos muito alta, é possível (mesmo com muita memória livre) que ela não seja satisfeita por não haver páginas de pedidos altos disponíveis. O kernel pode desfragmentar a memória (isso é chamado de compactação de memória) movendo muitas páginas de baixa ordem para que não deixem lacunas no espaço RAM endereçável.

O OOM-killer foi invocado? Por que?

Então, se levarmos essas coisas em conta, podemos dizer o seguinte;

Foi tentada uma alocação contígua de 32kB. Da zona normal.
Havia memória livre suficiente na zona selecionada.
Havia memória de ordem 3, 5 e 6 disponível13*32kB (MR) 1*128kB (R) 1*256kB (R)

Então, se houvereramemória livre, outras ordenspoderiasatisfazer o pedido. o que aconteceu?

Bem, a alocação de um pedido envolve mais do que apenas verificar a quantidade de memória livre disponível para esse pedido ou superior. O kernel subtrai efetivamente a memória de todas as ordens inferiores da linha livre total e, em seguida, executa a verificação mínima da marca d'água no que resta.

O que acontece no seu caso é verificar nossa memória livre para aquela zona que devemos fazer.

115000 - (5360*4) - (3667*8) - (3964*16) = 800

Essa quantidade de memória livre é verificada em relação à minmarca d’água, que é 3044. Assim, tecnicamente falando – você não tem mais memória livre para fazer a alocação solicitada. E é por isso que você invocou o OOM-killer.

Consertando

Existem duas soluções. A atualização para 64 bits altera o particionamento de zona de modo que 'Normal' seja de 4 GB a 36 GB, para que você não acabe 'padronizando' sua alocação de memória em uma zona que pode ficar tão fragmentada. Não é que você tenha mais memória endereçável que resolve esse problema (porque você já está usando PAE), apenas que a zona selecionada tem mais memória endereçável.

A segunda maneira (que nunca testei) é tentar fazer com que o kernel compacte sua memória de forma mais agressiva.

Se você alterar o valor de vm.extfrag_threshold500 para 100, é mais provável que a memória seja compactada na tentativa de honrar uma alocação de ordem superior. Embora eu nunca tenha mexido com esse valor antes - também dependerá de qual é o seu índice de fragmentação disponível em /sys/kernel/debug/extfrag/extfrag_index. Eu não tenho uma caixa no momento com um kernel novo o suficiente para ver o que isso mostra para oferecer mais do que isso.

Alternativamente, você pode executar algum tipo de trabalho cron (isso é terrivelmente feio) para compactar manualmente a memória, escrevendo em /proc/sys/vm/compact_memory.

Sinceramente, não acho que exista realmente uma maneira de ajustar o sistema para evitar esse problema - é da natureza do alocador de memória funcionar dessa maneira. Alterar a arquitetura da plataforma que você usa é provavelmente a única solução fundamentalmente solucionável.

Answer

Uma abordagem de 'marreta' seria atualizar para um sistema operacional de 64 bits (isto é 32 bits) porque o layout das zonas é feito de forma diferente.

OK, então aqui tentarei responder por que você experimentou um OOM aqui. Há uma série de fatores em jogo aqui.

O tamanho do pedido da solicitação e como o kernel trata determinados tamanhos de pedido.
A zona que está sendo selecionada.
As marcas d'água que esta zona usa.
Fragmentação na zona.

Se você olhar para o próprio OOM, há claramente muita memória livre disponível, mas o OOM-killer foi invocado? Por que?

O tamanho do pedido da solicitação e como o kernel trata determinados tamanhos de pedido

O kernel aloca memória por ordem. Um 'pedido' é uma região de RAM contígua que deve ser atendida para que a solicitação funcione. Os pedidos são organizados por ordens de magnitude (daí o nome ordem) usando o algoritmo 2^(ORDER + 12). Portanto, a ordem 0 é 4.096, a ordem 1 é 8.192, a ordem 2 é 16.384 e assim por diante.

O kernel possui um valor codificado do que é considerado uma 'ordem superior' (> PAGE_ALLOC_COSTLY_ORDER). Esta é a ordem 4 e superior (64kb ou superior é uma ordem superior).

Os pedidos mais altos são atendidos para alocações de páginas de maneira diferente dos pedidos mais baixos. Uma alocação de alta ordem se não conseguir capturar a memória, nos kernels modernos o fará.

Tente executar a rotina de compactação de memória para desfragmentar a memória.
Nuncachame o OOM-killer para atender à solicitação.

O tamanho do seu pedido está listado aqui

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

A ordem 3 é a mais alta das solicitações de ordem inferior e (como você pode ver) invoca o OOM-killer na tentativa de satisfazê-la.

Observe que a maioria das alocações de espaço de usuário não usa solicitações de ordem superior. Normalmente é o kernel que requer regiões contíguas de memória. Uma exceção a isso pode ser quando o espaço do usuário está usando páginas enormes - mas esse não é o caso aqui.

No seu caso, a alocação de ordem 3 é chamada pelo kernel que deseja enfileirar um pacote na pilha de rede - exigindo uma alocação de 32kb para fazer isso.

A zona que está sendo selecionada.

O kernel divide suas regiões de memória em zonas. Essa divisão é feita porque no x86 certas regiões da memória só são endereçáveis por determinados hardwares. Hardware mais antigo só pode endereçar memória na zona 'DMA', por exemplo. Quando queremos alocar alguma memória, primeiro uma zona é escolhida eapenasa memória livre desta zona é contabilizada ao tomar uma decisão de alocação.

Embora eu não tenha conhecimento total do algoritmo de seleção de zona, o caso de uso típico nunca é alocar do DMA, mas geralmente selecionar a zona endereçável mais baixa que possa satisfazer a solicitação.

Muitas informações de zona são divulgadas durante o OOM, que também podem ser obtidas em /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

As zonas que você possui, DMA, Normal e HighMem indicam uma plataforma de 32 bits, pois a zona HighMem é inexistente em 64 bits. Também em sistemas de 64 bits, o Normal é mapeado para 4 GB e além, enquanto em 32 bits ele mapeia até 896 MB (embora, no seu caso, o kernel relate apenas o gerenciamento de uma parte menor do que esta: - managed:587540kB.)

É possível saber de onde veio essa alocação olhando novamente a primeira linha, gfp_mask=0x42d0que nos diz que tipo de alocação foi feita. O último byte (0) nos diz que esta é uma alocação da zona normal. Os significados do gfp estão localizados eminclude/linux/gfp.h.

As marcas d'água que esta zona usa.

Quando a memória está baixa, as ações para recuperá-la são especificadas pela marca d’água. Eles aparecem aqui: min:3044kB low:3804kB high:4564kB. Se a memória livre atingir o nível 'baixo', a troca ocorrerá até ultrapassarmos o limite 'alto'. Se a memória atingir 'min', precisamos eliminar coisas para liberar memória por meio do OOM-killer.

Fragmentação na zona.

Para verificar se uma solicitação para uma ordem específica de memória pode ser atendida, o kernel contabiliza quantas páginas livres e disponíveis de cada ordem. Isso pode ser lido em /proc/buddyinfo. Os relatórios do OOM-killer também revelam as informações do amigo, conforme visto aqui:

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

Para que uma alocação de memória seja satisfeita, hádevehaver memória livre disponível no tamanho do pedido solicitado ou em uma alocação superior. Ter muitos dados livres nas ordens inferiores e nenhum nas ordens superiores significa que sua memória está fragmentada. Se você obtiver uma alocação de pedidos muito alta, é possível (mesmo com muita memória livre) que ela não seja satisfeita por não haver páginas de pedidos altos disponíveis. O kernel pode desfragmentar a memória (isso é chamado de compactação de memória) movendo muitas páginas de baixa ordem para que não deixem lacunas no espaço RAM endereçável.

O OOM-killer foi invocado? Por que?

Então, se levarmos essas coisas em conta, podemos dizer o seguinte;

Foi tentada uma alocação contígua de 32kB. Da zona normal.
Havia memória livre suficiente na zona selecionada.
Havia memória de ordem 3, 5 e 6 disponível13*32kB (MR) 1*128kB (R) 1*256kB (R)

Então, se houvereramemória livre, outras ordenspoderiasatisfazer o pedido. o que aconteceu?

Bem, a alocação de um pedido envolve mais do que apenas verificar a quantidade de memória livre disponível para esse pedido ou superior. O kernel subtrai efetivamente a memória de todas as ordens inferiores da linha livre total e, em seguida, executa a verificação mínima da marca d'água no que resta.

O que acontece no seu caso é verificar nossa memória livre para aquela zona que devemos fazer.

115000 - (5360*4) - (3667*8) - (3964*16) = 800

Essa quantidade de memória livre é verificada em relação à minmarca d’água, que é 3044. Assim, tecnicamente falando – você não tem mais memória livre para fazer a alocação solicitada. E é por isso que você invocou o OOM-killer.

Consertando

Existem duas soluções. A atualização para 64 bits altera o particionamento de zona de modo que 'Normal' seja de 4 GB a 36 GB, para que você não acabe 'padronizando' sua alocação de memória em uma zona que pode ficar tão fragmentada. Não é que você tenha mais memória endereçável que resolve esse problema (porque você já está usando PAE), apenas que a zona selecionada tem mais memória endereçável.

A segunda maneira (que nunca testei) é tentar fazer com que o kernel compacte sua memória de forma mais agressiva.

Se você alterar o valor de vm.extfrag_threshold500 para 100, é mais provável que a memória seja compactada na tentativa de honrar uma alocação de ordem superior. Embora eu nunca tenha mexido com esse valor antes - também dependerá de qual é o seu índice de fragmentação disponível em /sys/kernel/debug/extfrag/extfrag_index. Eu não tenho uma caixa no momento com um kernel novo o suficiente para ver o que isso mostra para oferecer mais do que isso.

Alternativamente, você pode executar algum tipo de trabalho cron (isso é terrivelmente feio) para compactar manualmente a memória, escrevendo em /proc/sys/vm/compact_memory.

Sinceramente, não acho que exista realmente uma maneira de ajustar o sistema para evitar esse problema - é da natureza do alocador de memória funcionar dessa maneira. Alterar a arquitetura da plataforma que você usa é provavelmente a única solução fundamentalmente solucionável.

Question 2

Desde o início: você deveriarealmenteopte por um sistema operacional de 64 bits. Você tem um bom motivo para permanecer em 32 bits aqui?

É difícil diagnosticar esse problema sem examinar o sistema mais de perto, de preferência no momento em que ele falha, então minha postagem (rápida) é mais ou menos genérica voltada para problemas de memória em sistemas de 32 bits. Eu mencionei que ir para 64 bits faria tudo isso desaparecer?

Seu problema é triplo.

Primeiro de tudo, mesmo em um kernel PAE, o espaço de endereço por processo é limitado a 4GiB[1]. Isso significa que sua instância do squid nunca será capaz de consumir mais de 4GiB de RAM por processo. Não estou familiarizado com o squid, mas se este for o seu servidor proxy principal, isso pode não ser suficiente.

Segundo, em um sistema de 32 bits com grandes quantidades de RAM, muita memória chamada 'ZONE_NORMAL' é usada para armazenar estruturas de dados necessárias para usar a memória em ZONE_HIGHMEM. Essas estruturas de dados não podem ser movidas para ZONE_HIGHMEM, porque a memória que o kernel usa para seus próprios propósitos deve estar sempre em ZONE_NORMAL (ou seja, no primeiro 1GiB-ish). Quanto mais memória você tiver em ZONE_HIGHMEM (muita, no seu caso), mais isso se tornará um problema, porque o kernel precisará de cada vez mais memória de ZONE_NORMAL para gerenciar ZONE_HIGHMEM. À medida que a quantidade de memória livre em ZONE_NORMAL se esgota, seu sistema pode falhar em algumas tarefas, porque ZONE_NORMAL é onde ummuitomuitas coisas acontecem em um sistema de 32 bits. Todas as operações de memória relacionadas ao kernel, por exemplo;)

Terceiro, mesmo que ainda haja alguma memória em ZONE_NORMAL (não examinei seus logs em detalhes), algumas operações de memória exigirão memória não fragmentada. Por exemplo, se toda a sua memória estiver fragmentada em pedaços muito pequenos, algumas operações que precisam de mais do que isso falharão. [3] Uma breve olhada em seus logs mostra uma quantidade bastante significativa de fragmentação em ZONE_DMA e ZONE_NORMAL.

Editar: a resposta de Mlfe acima tem uma excelente explicação detalhada de como isso funciona.

Novamente: em um sistema de 64 bits, toda a memória está em ZONE_NORMAL. Não há zona HIGHMEM em sistemas de 64 bits. Problema resolvido.

Editar: você pode dar uma olhada aqui [4] para ver se consegue dizer ao oom-killer para deixar seus processos importantes de lado. Isso não resolverá tudo (se é que resolverá alguma coisa), mas pode valer a pena tentar.

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.htmlehttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernel s-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Answer

Desde o início: você deveriarealmenteopte por um sistema operacional de 64 bits. Você tem um bom motivo para permanecer em 32 bits aqui?

É difícil diagnosticar esse problema sem examinar o sistema mais de perto, de preferência no momento em que ele falha, então minha postagem (rápida) é mais ou menos genérica voltada para problemas de memória em sistemas de 32 bits. Eu mencionei que ir para 64 bits faria tudo isso desaparecer?

Seu problema é triplo.

Primeiro de tudo, mesmo em um kernel PAE, o espaço de endereço por processo é limitado a 4GiB[1]. Isso significa que sua instância do squid nunca será capaz de consumir mais de 4GiB de RAM por processo. Não estou familiarizado com o squid, mas se este for o seu servidor proxy principal, isso pode não ser suficiente.

Segundo, em um sistema de 32 bits com grandes quantidades de RAM, muita memória chamada 'ZONE_NORMAL' é usada para armazenar estruturas de dados necessárias para usar a memória em ZONE_HIGHMEM. Essas estruturas de dados não podem ser movidas para ZONE_HIGHMEM, porque a memória que o kernel usa para seus próprios propósitos deve estar sempre em ZONE_NORMAL (ou seja, no primeiro 1GiB-ish). Quanto mais memória você tiver em ZONE_HIGHMEM (muita, no seu caso), mais isso se tornará um problema, porque o kernel precisará de cada vez mais memória de ZONE_NORMAL para gerenciar ZONE_HIGHMEM. À medida que a quantidade de memória livre em ZONE_NORMAL se esgota, seu sistema pode falhar em algumas tarefas, porque ZONE_NORMAL é onde ummuitomuitas coisas acontecem em um sistema de 32 bits. Todas as operações de memória relacionadas ao kernel, por exemplo;)

Terceiro, mesmo que ainda haja alguma memória em ZONE_NORMAL (não examinei seus logs em detalhes), algumas operações de memória exigirão memória não fragmentada. Por exemplo, se toda a sua memória estiver fragmentada em pedaços muito pequenos, algumas operações que precisam de mais do que isso falharão. [3] Uma breve olhada em seus logs mostra uma quantidade bastante significativa de fragmentação em ZONE_DMA e ZONE_NORMAL.

Editar: a resposta de Mlfe acima tem uma excelente explicação detalhada de como isso funciona.

Novamente: em um sistema de 64 bits, toda a memória está em ZONE_NORMAL. Não há zona HIGHMEM em sistemas de 64 bits. Problema resolvido.

Editar: você pode dar uma olhada aqui [4] para ver se consegue dizer ao oom-killer para deixar seus processos importantes de lado. Isso não resolverá tudo (se é que resolverá alguma coisa), mas pode valer a pena tentar.

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.htmlehttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernel s-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Question 3

@MIfe já forneceuexcelente artigo sobre como as alocações de memória no kernel são tratadase também forneceu a solução adequada, como mudar para o sistema operacional de 64 bits e hacks desagradáveis, como compactação manual de memória via /proc/sys/vm/compact_memoryin cron.

Meus 2 centavos seriam outra solução alternativa que pode ajudá-lo:
notei que você tem tcp_tso_segmentbacktrace em seu kernel, fazendo isso:

# ethtool -K ethX tso off gso off lro off

pode diminuir a pressão, mmforçando-o a usar ordens mais baixas.

PS. lista de todos os descarregamentos pode ser obtida via# ethtool -k ethX

Answer

@MIfe já forneceuexcelente artigo sobre como as alocações de memória no kernel são tratadase também forneceu a solução adequada, como mudar para o sistema operacional de 64 bits e hacks desagradáveis, como compactação manual de memória via /proc/sys/vm/compact_memoryin cron.

Meus 2 centavos seriam outra solução alternativa que pode ajudá-lo:
notei que você tem tcp_tso_segmentbacktrace em seu kernel, fazendo isso:

# ethtool -K ethX tso off gso off lro off

pode diminuir a pressão, mmforçando-o a usar ordens mais baixas.

PS. lista de todos os descarregamentos pode ser obtida via# ethtool -k ethX

Question 4

O pânico ocorre porque o sysctl "vm.panic_on_oom = 1" está definido - a ideia é que a reinicialização do sistema o retorne a um estado sensato. Você pode alterar isso em sysctl.conf.

Bem no topo, lemos o assassino de oom invocado por lula. Você pode verificar a configuração do squid e o uso máximo de memória (ou apenas mudar para um sistema operacional de 64 bits).

/proc/meminfo mostra a zona de alta memória em uso, então você está executando um kernel de 32 bits com 36 GB de memória. Você também pode ver que na zona normal, para atender à demanda de memória do squid, o kernel escaneou 982 páginas sem sucesso:

pages_scanned:982 all_unreclaimable? yes

Answer

O pânico ocorre porque o sysctl "vm.panic_on_oom = 1" está definido - a ideia é que a reinicialização do sistema o retorne a um estado sensato. Você pode alterar isso em sysctl.conf.

Bem no topo, lemos o assassino de oom invocado por lula. Você pode verificar a configuração do squid e o uso máximo de memória (ou apenas mudar para um sistema operacional de 64 bits).

/proc/meminfo mostra a zona de alta memória em uso, então você está executando um kernel de 32 bits com 36 GB de memória. Você também pode ver que na zona normal, para atender à demanda de memória do squid, o kernel escaneou 982 páginas sem sucesso:

pages_scanned:982 all_unreclaimable? yes

Situação oom do Linux (kernel de 32 bits)

Responder1

O tamanho do pedido da solicitação e como o kernel trata determinados tamanhos de pedido

A zona que está sendo selecionada.

As marcas d'água que esta zona usa.

Fragmentação na zona.

O OOM-killer foi invocado? Por que?

Consertando

Responder2

Responder3

Responder4

informação relacionada