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

Portanto, vamos ler a saída do oom-killer e ver o que pode ser aprendido a partir daí.

Ao analisar logs OOM killer, é 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, order=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ágina nas potências de 2, então o clamd solicitou 2 ⁰ páginas de memória ou 4KB.

Os dois bits mais baixos do GFP_MASK (obter máscara de página gratuita) constituem a chamada má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 questões de compatibilidade. Em uma 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, o zonemask é 0, o que significa que clamd está solicitando memória de ZONE_NORMAL.

As outras 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 com a documentação do Linux MM , portanto, sua solicitação tem os sinalizadores para GFP_ZERO, GFP_REPEAT, e GFP_FS, portanto, não é particularmente exigente.GFP_IOGFP_WAIT

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

[kernel] [1772321.850770] Normal livre:8056kB min:8048kB baixo:10060kB alto:12072kB active_anon:0kB inactive_anon:0kB active_file:248kB inactive_file:388kB unevictable:0kB isolado(anon) :0kB isolado(arquivo):0kB presente:890008kB

Notável aqui é que freeé apenas 8K de mine muito abaixo low. Isso significa que o gerenciador de memória do seu host está com problemas e o kswapd já deve estar trocando as páginas, pois está na fase amarela 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 de 4 KB.

Então vamos recapitular:

• você tem um processo userland ( clamd) obtendo memória, ZONE_NORMALenquanto a alocação de memória não privilegiada geralmente seria executada a partirZONE_HIMEM
• o gerenciador de memória deve, neste estágio, ser capaz de atender à página 4K solicitada, embora você pareça ter uma pressão de memória significativa emZONE_NORMAL
• o sistema, pelas kswapdregras do , deveria ter visto alguma atividade de paginação de antemão, mas nada está sendo trocado, mesmo sob pressão de memória em ZONE_NORMAL, sem causa aparente
• Nenhuma das opções acima dá uma razão definitiva de por que oom-killerfoi invocado

Tudo isso parece bastante estranho, mas pelo menos deve estar relacionado ao que está descrito na seção 2.5 do excelente livro de John O'Gorman "Entendendo o Linux Virtual Memory Manager" :

Como o espaço de endereços utilizável pelo kernel (ZONE_NORMAL) é limitado em tamanho, o kernel tem suporte para o conceito de High Memory. [...] Para acessar a memória entre o intervalo de 1GiB e 4GiB, o kernel mapeia temporariamente as páginas da memória alta em 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, 176MiB de memória são consumidos, colocando uma pressão significativa em ZONE_NORMAL. Isso não parece tão ruim até que outras estruturas sejam levadas em consideração que usam ZONE_NORMAL. Mesmo estruturas muito pequenas, como entradas de tabela de páginas (PTEs), requerem cerca de 16MiB no pior caso. Isso faz com que 16GiB seja 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, essa não é uma resposta definitiva, mas uma dica muito forte que eu seguiria primeiro. Reduza a memória utilizável do host para no máximo 16 G usando o mem=parâmetro do kernel ou removendo metade dos DIMMs do servidor.

Por fim, use um Kernel de 64 bits .

Cara, é 2015.

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ão muito baixos, 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]. Consulte https://www.maketecheasier.com/swap-partitions-on-linux/

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

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

Faça algumas execuções de teste sem opções. Faça isso com arquivos menores, digamos 10 GB - isso deve evitar o pânico do kernel, mas ainda permite que você monitore o comportamento que está causando o problema. Monitore o uso de memória do rsync.

Gradualmente, adicione opções de retorno, 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 RAM do rsync cresce 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 in-ram, você precisará do 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. O mmap não oferece garantia de que será liberado no disco até que o arquivo seja fechado [ao contrário da leitura/gravação], que vai para o cache do bloco FS imediatamente [onde será liberado]

(2) A falha/pânico do kernel está ocorrendo quando o tamanho da transferência atinge o tamanho da RAM. Claramente, o rsync está pegando tanta memória não fscache via malloc ou mmap. Mais uma vez, com as opções que você especificou, 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 de arquivo de 24 GB novamente. Ele explodirá em 16 GB em vez de 32 GB. Isso confirmará que o rsync realmente precisa da 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/crash.

(5) As chances são de que o rsync esteja atingindo a troca, mas acontece muito rápido para ver com o top antes que o OOM entre em ação e mate o rsync. No momento em que o rsync chega a 32 GB, outros processos já foram forçados a trocar, principalmente se estiverem ociosos. Talvez uma combinação de "livre" e "top" lhe dê uma imagem melhor.

(6) Depois que o rsync é morto, leva 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, OOM tem um bug. Caso contrário, não haveria um acidente.

(7) Na minha experiência, uma vez que 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 o mato, 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 rsync sem opções. Isso vai funcionar. Obtenha um exemplo de linha de base para trabalhar. Em seguida, adicione de volta --inplace e teste novamente. Em seguida, faça --append-verify em vez disso. Então, experimente os dois. Descubra qual opção obtém o rsync fazendo o enorme mmap. Em seguida, 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 ter a 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 o mem= e os testes de arquivos menores acima.

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

Eu li [mas esqueci] sobre o sistema ser de 32 bits. Portanto, concordo que 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 se arrasta na mesma taxa 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 várias centenas de vezes/seg. Você pode executar isso com uma prioridade mais alta 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, com sorte, durante o OOM, para que você possa ver por que o OOM enlouquece:

/proc/meminfo -- para obter mais informações sobre o uso de troca 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)

/proc/rsync_pid/fd directory. Reading the symlinks will allow you to identify which fd is opened on the target file (e.g. readlink of /proc/rsync_pid/fd/5 --> target_file). This probably only needs to be done once to get the fd number [it should stay fixed]

Knowing the fd number, look at /proc/rsync_pid/fdinfo/fd. It's a text file that looks like:

pos: <file_position>
flags: blah_blah
mnt_id: blah_blah

Monitoring the "pos" value can be helpful as the "last file position" may be useful. If you do several tests with varying sizes and mem= options, does the last file position track any of these [and how]? The usual suspect: file position == available RAM

But, the simplest way is to start with "rsync local_file server:remote_file" and verify that works. You may be able to get similar [but faster] results by doing "ssh server rsync file_a file_b" [you'd need to create a 50GB file_a first]. A simple way to create file_a is scp local_system:original_file server:file_a and this might be interesting unto itself (e.g. does this work when the rsync crashes? If scp works, but rsync fails, this points to rsync. If scp fails, this points to something else like the NIC driver). Doing the ssh rsync also takes the NIC out of the equation, which may be helpful. If that hoses the system, then something is really wrong. If it succeeds, [as I've mentioned] start adding back the options one-by-one.

I hate to belabor the point, but adding some swap via swap-to-file may change/delay the crash behavior and may be useful as a diagnostic tool. If adding, say 16GB, of swap delays the crash [as measured by memory usage or target file position] from 32GB to 46GB, then that will say something.

It may not be any particular process, but an errant kernel driver that is chewing memory. The kernel's internal vmalloc allocates stuff and it can be swapped out. IIRC, it's not bound by addressibility under all circumstances.

Clearly, the OOM is getting confused/panicked. That is, it kills rsync, but doesn't see the memory freed up in a timely manner and goes looking for other victims. Some of them are probably critical to system operation.

malloc/mmap aside, this could be caused by unflushed FS cache that takes a long time (e.g. with 30GB of unflushed data, assuming a disk rate of 300 MB/sec, it might take 100 seconds to flush it). Even at that rate, OOM may be too impatient. Or, OOM killing rsync doesn't start the FS flush fast enough [or at all]. Or FS flush happens fast enough, but it has a "lazy" release of the pages back to the free pool. There are some /proc options you can set to control FS cache behavior [I can't remember what they are].

Try booting with mem=4G or some other small number. This might cut back on the FS cache and shorten its flush time to keep OOM from looking for other things to kill (e.g. flush time is reduced from 100 sec to < 1 sec). It might also unmask an OOM bug that can't handle physical ram > 4GB on a 32 bit system or some such.

Also, an important point: Run as non-root. Root users are never expected to chew resources, so they are given more forgiving limits (e.g. 99% of memory vs 95% for non-root users). This may explain why OOM is in such a state. Also, this gives OOM et. al. more headroom to do its job of reclaiming memory.

clamd? Parece que você está usando o ClamAV e tem a verificação de acesso habilitada, onde o mecanismo antivírus tenta verificar arquivos abertos em busca de vírus, carregando na memória todo o conteúdo de cada arquivo aberto por qualquer outro processo .

Dependendo da sua postura de segurança e da necessidade dessa transferência, você deve avaliar a desativação da varredura no acesso do ClamAV enquanto realiza a transferência.