Rsync acionou o Linux OOM killer em um único arquivo de 50 GB

Question 1

Então, vamos ler o resultado do oom-killer e ver o que pode ser aprendido com ele.

Ao analisar os logs do Killer OOM, é importante observar o que o desencadeou. A primeira linha do seu log nos dá algumas pistas:

[kernel] [1772321.850644] clamd invocou oom-killer:gfp_mask=0x84d0, pedido=0

order=0está nos dizendo quanta memória está sendo solicitada. O gerenciamento de memória do kernel só é capaz de gerenciar números de páginas em potências de 2, então clamd solicitou 2 ⁰ páginas de memória ou 4 KB.

Os dois bits mais baixos do GFP_MASK (obter máscara de página gratuita) constituem o chamadomáscara de zona informando ao alocador de qual zona obter a memória:

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

Zonas de memóriaé um conceito criado principalmente por razões de compatibilidade. Numa visão simplificada, existem três zonas para um Kernel x86:

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

No seu caso, zonemask é 0, o que significa que clamd está solicitando memória de ZONE_NORMAL.

As demais bandeiras estão resolvendo

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

de acordo comDocumentação Linux MM, portanto , sua solicitação tem os sinalizadores para GFP_ZERO, GFP_REPEAT, e , portanto, não sendo particularmente exigente.GFP_FSGFP_IOGFP_WAIT

Então, o que há ZONE_NORMAL? Algumas estatísticas genéricas podem ser encontradas mais adiante na saída do OOM:

[núcleo] [1772321.850770] Normallivre: 8.056 kB mínimo: 8.048 kB baixo: 10.060 kBalto: 12072kB ativo_anon:0kB inativo_anon:0kB arquivo_ativo:248kB arquivo_inativo:388kB inevitável:0kB isolado(anon) :0kB isolado(arquivo):0kB presente:890008kB

Notável aqui é quefreeestá a apenas 8K demine bem abaixolow. Isso significa que o gerenciador de memória do seu host está em apuros e o kswapd já deve estar trocando as páginas como está noamarelofase do gráfico abaixo:

Mais algumas informações sobre a fragmentação de memória da zona são fornecidas aqui:

[kernel] [1772321.850795] Normal: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB

basicamente afirmando que você tem uma única página contígua de 4 MB com o restante fortemente fragmentado em páginas principalmente de 4 KB.

Então vamos recapitular:

você tem um processo de usuário ( clamd) obtendo memória, ZONE_NORMALenquanto a alocação de memória sem privilégios normalmente seria realizada a partir deZONE_HIMEM
o gerenciador de memória neste estágio deveria ter sido capaz de atender a página 4K solicitada, embora você pareça ter uma pressão de memória significativa emZONE_NORMAL
o sistema, pelas kswapdregras de,devevi alguma atividade de paginação anteriormente, mas nada está sendo trocado, mesmo sob pressão de memória ZONE_NORMAL, sem causa aparente
Nenhuma das opções acima fornece uma razão definitiva para o porquê de oom-killerter sido invocado

Tudo isso parece bastante estranho, mas pelo menos deve estar relacionado com o que é descrito noseção 2.5 do excelente livro "Understanding the Linux Virtual Memory Manager" de John O'Gorman:

Como o espaço de endereços utilizável pelo kernel (ZONE_NORMAL) é limitado em tamanho, o kernel tem suporte para o conceito de Alta Memória. [...] Para acessar a memória entre o intervalo de 1GiB e 4GiB, o kernel mapeia temporariamente páginas de alta memória para ZONE_NORMAL com kmap(). [...]

Isso significa que para descrever 1GiB de memória, são necessários aproximadamente 11MiB de memória do kernel. Assim, com 16GiB, são consumidos 176MiB de memória, colocando uma pressão significativa em ZONE_NORMAL. Isso não parece tão ruim até que outras estruturas que usam ZONE_NORMAL sejam levadas em consideração. Mesmo estruturas muito pequenas, como entradas de tabela de páginas (PTEs), requerem cerca de 16 MiB no pior caso.Isso torna 16GiB o limite prático para memória física disponível no Linux em um x86.

(o destaque é meu)

Como o 3.2 tem vários avanços no gerenciamento de memória em relação ao 2.6, esta não é uma resposta definitiva, mas uma dica realmente forte que eu seguiria primeiro. Reduza a memória utilizável do host para no máximo 16G usando o mem=parâmetro do kernel ou extraindo metade dos DIMMs do servidor.

Em última análise,use um kernel de 64 bits.

Cara, estamos em 2015.

Answer

Então, vamos ler o resultado do oom-killer e ver o que pode ser aprendido com ele.

Ao analisar os logs do Killer OOM, é importante observar o que o desencadeou. A primeira linha do seu log nos dá algumas pistas:

[kernel] [1772321.850644] clamd invocou oom-killer:gfp_mask=0x84d0, pedido=0

order=0está nos dizendo quanta memória está sendo solicitada. O gerenciamento de memória do kernel só é capaz de gerenciar números de páginas em potências de 2, então clamd solicitou 2 ⁰ páginas de memória ou 4 KB.

Os dois bits mais baixos do GFP_MASK (obter máscara de página gratuita) constituem o chamadomáscara de zona informando ao alocador de qual zona obter a memória:

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

Zonas de memóriaé um conceito criado principalmente por razões de compatibilidade. Numa visão simplificada, existem três zonas para um Kernel x86:

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

No seu caso, zonemask é 0, o que significa que clamd está solicitando memória de ZONE_NORMAL.

As demais bandeiras estão resolvendo

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

de acordo comDocumentação Linux MM, portanto , sua solicitação tem os sinalizadores para GFP_ZERO, GFP_REPEAT, e , portanto, não sendo particularmente exigente.GFP_FSGFP_IOGFP_WAIT

Então, o que há ZONE_NORMAL? Algumas estatísticas genéricas podem ser encontradas mais adiante na saída do OOM:

[núcleo] [1772321.850770] Normallivre: 8.056 kB mínimo: 8.048 kB baixo: 10.060 kBalto: 12072kB ativo_anon:0kB inativo_anon:0kB arquivo_ativo:248kB arquivo_inativo:388kB inevitável:0kB isolado(anon) :0kB isolado(arquivo):0kB presente:890008kB

Notável aqui é quefreeestá a apenas 8K demine bem abaixolow. Isso significa que o gerenciador de memória do seu host está em apuros e o kswapd já deve estar trocando as páginas como está noamarelofase do gráfico abaixo:

Mais algumas informações sobre a fragmentação de memória da zona são fornecidas aqui:

[kernel] [1772321.850795] Normal: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB

basicamente afirmando que você tem uma única página contígua de 4 MB com o restante fortemente fragmentado em páginas principalmente de 4 KB.

Então vamos recapitular:

você tem um processo de usuário ( clamd) obtendo memória, ZONE_NORMALenquanto a alocação de memória sem privilégios normalmente seria realizada a partir deZONE_HIMEM
o gerenciador de memória neste estágio deveria ter sido capaz de atender a página 4K solicitada, embora você pareça ter uma pressão de memória significativa emZONE_NORMAL
o sistema, pelas kswapdregras de,devevi alguma atividade de paginação anteriormente, mas nada está sendo trocado, mesmo sob pressão de memória ZONE_NORMAL, sem causa aparente
Nenhuma das opções acima fornece uma razão definitiva para o porquê de oom-killerter sido invocado

Tudo isso parece bastante estranho, mas pelo menos deve estar relacionado com o que é descrito noseção 2.5 do excelente livro "Understanding the Linux Virtual Memory Manager" de John O'Gorman:

Como o espaço de endereços utilizável pelo kernel (ZONE_NORMAL) é limitado em tamanho, o kernel tem suporte para o conceito de Alta Memória. [...] Para acessar a memória entre o intervalo de 1GiB e 4GiB, o kernel mapeia temporariamente páginas de alta memória para ZONE_NORMAL com kmap(). [...]

Isso significa que para descrever 1GiB de memória, são necessários aproximadamente 11MiB de memória do kernel. Assim, com 16GiB, são consumidos 176MiB de memória, colocando uma pressão significativa em ZONE_NORMAL. Isso não parece tão ruim até que outras estruturas que usam ZONE_NORMAL sejam levadas em consideração. Mesmo estruturas muito pequenas, como entradas de tabela de páginas (PTEs), requerem cerca de 16 MiB no pior caso.Isso torna 16GiB o limite prático para memória física disponível no Linux em um x86.

(o destaque é meu)

Como o 3.2 tem vários avanços no gerenciamento de memória em relação ao 2.6, esta não é uma resposta definitiva, mas uma dica realmente forte que eu seguiria primeiro. Reduza a memória utilizável do host para no máximo 16G usando o mem=parâmetro do kernel ou extraindo metade dos DIMMs do servidor.

Em última análise,use um kernel de 64 bits.

Cara, estamos em 2015.

Question 2

Algumas coisas ...

Minha regra geral para espaço de troca é ter pelo menos 2x a quantidade de memória RAM física. Isso permite que o daemon de página/swap reorganize a memória com eficiência.

Server_B tem 32 GB de RAM, então tente configurá-lo para 64 GB de swap. IMO, os 2 GB de espaço de troca que seu servidor possui sãocaminhomuito baixo, especialmente para um servidor.

Se você não tiver uma partição extra que possa transformar em uma partição swap, você pode testar isso criando um arquivo e montando-o como uma partição swap [será lento]. Verhttps://www.maketecheasier.com/swap-partitions-on-linux/

Como server_B tem bastante espaço em disco, --inplace não é necessário e pode ser indesejado, pois pode ser o que está fazendo com que o rsync use 32 GB. --inplace só é realmente útil se você tiver pouco espaço no sistema de arquivos [o que não tem] ou tiver algum requisito especial de desempenho.

Meu palpite é que o rsync desejará usar 50 GB de RAM [o tamanho do arquivo] com suas opções atuais. Normalmente, o rsync não precisa de tanta memória para fazer seu trabalho, então uma ou mais de suas opções podem ser o problema. Eu rotineiramente transfiro arquivos de 200 GB sem problemas.

Faça alguns testes sem opções. Faça isso com arquivos menores, digamos 10 GB - isso deve evitar o kernel panic, mas ainda permitirá monitorar o comportamento que está causando o problema. Monitore o uso de memória do rsync.

Gradualmente, adicione novamente opções, uma de cada vez, para ver qual opção [ou combinação de opções] faz com que o rsync comece a consumir RAM (por exemplo, enquanto a transferência está acontecendo, o uso de memória RAM do rsync aumenta proporcionalmente à quantidade de dados de arquivo transferidos, etc.).

Se você realmente precisa das opções que fazem com que o rsync mantenha alguma imagem de arquivo na memória RAM, você precisará de espaço de troca extra e o tamanho máximo do arquivo será limitado de acordo.

Mais algumas coisas [ATUALIZADO]:

(1) O rastreamento da pilha do kernel mostra que o rsync estava com falha de página em uma área mmap. Provavelmente está mapeando o arquivo. mmap não oferece garantia de que será liberado para o discoatéo arquivo é fechado [ao contrário de leitura/gravação], que vai para o cache do bloco FS imediatamente [onde será liberado]

(2) A falha/pânico do kernel ocorre quando o tamanho da transferência atinge o tamanho da RAM. Claramente, o rsync está capturando muita memória não-fscache via malloc ou mmap. Mais uma vez, com as opções especificadas, o rsync alocará 50 GB de memória para transferir um arquivo de 50 GB.

(3) Transfira um arquivo de 24 GB. Isso provavelmente funcionará. Em seguida, inicialize o kernel com mem=16G e faça o teste do arquivo de 24GB novamente. Ele explodirá em 16 GB em vez de 32 GB. Isso confirmará que o rsync realmente precisa de memória.

(4) Antes de dizer que adicionar swap é ridículo, tente adicionar alguns [através do método swap-to-file]. Isso é muito mais fácil de fazer e testar do que todos os argumentos acadêmicos sobre como a troca não é necessária. Mesmo que não seja a solução, você pode aprender algo com isso. Aposto que o teste mem=16G será bem-sucedido sem pânico/travamento.

(5) Provavelmente, rsyncébater em swap, mas acontece muito rápido para ver com top antes que o OOM entre em ação e mate o rsync. Quando o rsync chega a 32 GB, outros processos já foram forçados a trocar, principalmente se estiverem ociosos. Talvez uma combinação de "grátis" e "top" lhe dê uma imagem melhor.

(6) Depois que o rsync é eliminado, leva algum tempo para liberar o mmap para o FS. Não é rápido o suficiente para OOM e começa a matar outras coisas [algumas são obviamente de missão crítica]. Ou seja, o mmap flush e o OOM estão correndo. Ou o OOM tem um bug. Caso contrário, não haveria acidente.

(7) Na minha experiência, quando um sistema “atinge a parede da memória”, o Linux leva muito tempo para se recuperar totalmente. E, às vezes, ele nunca se recupera adequadamente e a única maneira de limpá-lo é reinicializando. Por exemplo, tenho 12 GB de RAM. Quando executo um trabalho que usa 40 GB de memória [tenho 120 GB de swap para acomodar trabalhos grandes] e depois o encerro, leva cerca de 10 minutos para o sistema retornar à capacidade de resposta normal [com a luz do disco acesa o tempo todo] .

(8) Execute o rsyncsemopções. Isso funcionará. Obtenha um exemplo básico para trabalhar. Em seguida, adicione novamente --inplace e teste novamente. Então faça --append-verify. Então, experimente os dois. Descubra qual opção faz com que o rsync faça o enorme mmap. Então decida se você pode viver sem ele. Se --inplace for o culpado, isso é óbvio, já que você tem bastante espaço em disco. Se você precisar dessa opção, precisará obter o espaço de troca para acomodar o malloc/mmap que o rsync fará.

SEGUNDA ATUALIZAÇÃO:

Por favor, faça os testes mem= e arquivos menores acima.

As questões centrais: Por que o rsync é eliminado pelo OOM? Quem/o que está mastigando memória?

Eu li [mas esqueci] que o sistema era de 32 bits. Portanto, eu concordo, o rsync pode não ser diretamente responsável (via malloc/mmap - glibc implementa grandes mallocs por meio de mmaps anônimos/privados), e a falha da página mmap do rsync apenas aciona o OOM por coincidência. Em seguida, o OOM calcula a memória total consumida pelo rsync direta e indiretamente [cache FS, buffers de soquete, etc.] e decide que é o principal candidato. Portanto, monitorar o uso total da memória pode ser útil. Eu suspeito que isso aumenta na mesma proporção que a transferência de arquivos. Obviamente, não deveria.

Algumas coisas que você pode monitorar em /proc ou /proc/rsync_pid por meio de um script perl ou python em um loop rápido [um script bash provavelmente não será rápido o suficiente para o evento de fim do mundo] que pode monitorar todos as seguintes centenas de vezes/seg. Você pode executar isso com uma prioridade mais alta do que o rsync, para que ele se mantenha na RAM e em execução, para que você possa monitorar as coisas antes da falha e, esperançosamente, durante o OOM, para que você possa ver por que o OOM enlouquece:

/proc/meminfo - para obter mais detalhes sobre o uso de swap no "ponto de impacto". Na verdade, obter o número final de quanta RAM está sendo usada no total pode ser mais útil. Embora top forneça isso, pode não ser rápido o suficiente para mostrar o estado do universo imediatamente antes do "big bang" (por exemplo, os últimos 10 milissegundos).

Diretório /proc/rsync_pid/fd. A leitura dos links simbólicos permitirá identificar qual fd está aberto no arquivo de destino (por exemplo, readlink de /proc/rsync_pid/fd/5 --> target_file). Provavelmente isso só precisa ser feito uma vez para obter o número fd [deve permanecer fixo]

Sabendo o número do fd, consulte /proc/rsync_pid/fdinfo/fd. É um arquivo de texto parecido com:

posição: <posição_do_arquivo>
bandeiras: blá_blá
mnt_id: blá_blá

Monitorar o valor "pos" pode ser útil, pois a "posição do último arquivo" pode ser útil. Se você fizer vários testes com tamanhos e opções mem= variados, a última posição do arquivo rastreia algum deles [e como]? O suspeito de sempre: posição do arquivo == RAM disponível

Porém, a maneira mais simples é começar com "rsync local_file server:remote_file" e verificar se funciona. Você pode obter resultados semelhantes [mas mais rápidos] executando "ssh server rsync file_a file_b" [você precisaria criar um file_a de 50 GB primeiro]. Uma maneira simples de criar file_a é scp local_system:original_file server:file_a e isso pode ser interessante por si só (por exemplo, isso funciona quando o rsync falha? Se o scp funcionar, mas o rsync falhar, isso aponta para o rsync. Se o scp falhar, isso aponta para algo como o driver da NIC). Fazer o ssh rsync também tira a NIC da equação, o que pode ser útil. Se isso mangueira o sistema, então algo está realmente errado. Se tiver sucesso, [como mencionei] comece a adicionar novamente as opções uma por uma.

Detesto insistir nesse ponto, mas adicionar alguma troca por meio de troca para arquivo pode alterar/atrasar o comportamento da falha e pode ser útil como ferramenta de diagnóstico. Se adicionar, digamos, 16 GB, de swap atrasar a falha [conforme medido pelo uso de memória ou posição do arquivo de destino] de 32 GB para 46 GB, então isso dirá alguma coisa.

Pode não ser um processo específico, mas um driver de kernel incorreto que está consumindo memória. O vmalloc interno do kernel aloca coisas e pode ser trocado. IIRC, não está vinculado à endereçamento em todas as circunstâncias.

Claramente, o OOM está ficando confuso/em pânico. Ou seja, ele mata o rsync, mas não vê a memória liberada em tempo hábil e sai em busca de outras vítimas. Alguns deles são provavelmente críticos para a operação do sistema.

Deixando de lado o malloc/mmap, isso pode ser causado por um cache FS não liberado que leva muito tempo (por exemplo, com 30 GB de dados não liberados, assumindo uma taxa de disco de 300 MB/s, pode levar 100 segundos para liberá-lo). Mesmo nesse ritmo, o OOM pode ser muito impaciente. Ou o OOM matando o rsync não inicia a liberação do FS rápido o suficiente [ou de todo]. Ou a liberação do FS acontece rápido o suficiente, mas tem uma liberação "preguiçosa" das páginas de volta ao pool livre. Existem algumas opções /proc que você pode definir para controlar o comportamento do cache FS [não me lembro quais são].

Tente inicializar com mem=4G ou algum outro número pequeno. Isso pode reduzir o cache do FS e o tempo de liberação para evitar que o OOM procure outras coisas para eliminar (por exemplo, o tempo de liberação é reduzido de 100 segundos para <1 segundo). Também pode desmascarar um bug OOM que não consegue lidar com memória RAM física> 4 GB em um sistema de 32 bits ou algo assim.

Além disso, um ponto importante: execute como não-root. Nunca se espera que os usuários root mastiguem recursos, portanto, eles recebem limites mais tolerantes (por exemplo, 99% de memória versus 95% para usuários não root). Isso pode explicar por que o OOM está nesse estado. Além disso, isso dá OOM et. al. mais espaço para fazer seu trabalho de recuperar a memória.

Answer