Falha na referência do Nullpointer em grandes alocações de memória no ESXi com convidados do Linux

Question

Eu acho que deve haver algum tipo de corrupção de memória. Os problemas ocorrem principalmente em processos que alocam grande quantidade de memória RAM (especialmente navegadores e cc1plus). JVMs com uso intensivo de memória RAM morrem quase no início, o Eclipse não pode nem mesmo criar sua primeira janela. O problema é quase sempre o segfault causado pela anulação de erros do ponteiro nulo.

O que eu experimentei:

• O Windows e o OSX executando os mesmos processos no ESXi não mostram o fenômeno.
• Mas: Linux com kernels diferentes (entre 3.6 e 4.1) mostra. Linux com diferentes distribuições (já tentei debian, ubuntu e opensuse) também mostra.
• convidados de 32 bits não são problemáticos, mesmo que sejam Linux.
• Embora a passagem PCI esteja ativada, sem ela (e mesmo com o IOMMU desativado no BIOS), o problema está chegando.
• Atualizar o esxi 5.5 para o 6 não ajudou em nada.

Outras informações:

• Eu corri o memtest uma noite na máquina host e não encontrei nenhum problema.
• Usando o sistema operacional de 64 bits no host (sem virtualização), o problema não está chegando.
• As falhas ocorrem principalmente após o processo alocar uma grande quantidade de memória.
• O problema ocorre quase sempre no espaço do usuário (mas sua razão pode ser que o kernelspace aloque grande quantidade de memória ram apenas raramente).
• Desativar aceleração ou alternar o sistema operacional convidado para "outro linux" ou "outro sistema operacional de 64 bits" não ajudou.
• Desligar o SMP na máquina convidada (ou seja, fornecer apenas um único núcleo da CPU) não ajudou. Jogar com outras configurações de CPU (várias configurações de multi-socket / multicore, limitando o convidado a vários núcleos de CPU) não teve nenhum efeito.
• A limitação da memória do sistema operacional convidado também não ajudou, embora os convidados que executam apenas alguns processos com baixo consumo de memória trabalhem sem problemas.
• Logo após o problema, o problema não acontece. Ele ocorre somente depois de ocorrer um grande ciclo livre de alocação de memória (por exemplo, somente após alguns minutos de cliques em um firefox).
• Alterar o tipo de controlador SCSI virtual de LSI para vmware paravirtual ou desativar o recurso de troca não ajudou.

Acho que algo corrompe (zera) a memória do sistema operacional convidado em grandes brk() chamadas.

Alguém encontrou esse problema? O que outro poderia ser feito para tornar a caça mais eficiente?

    

Answer 1

Problema resolvido.

Foi um módulo de memória danificado, que o memtest não conseguiu detectar. : -)

E o problema aconteceu mesmo com o Windows e o OSX, mas depois.

Nunca se esqueça: o memtest não consegue encontrar sempre todos os problemas de ram! O motivo: memtest percorre a memória e faz operações complexas nela. Mas deixando áreas de memória por muito tempo sem uso, isso não acontece.

A memória DIMM é essencialmente uma grande variedade de condensadores. Esses condensadores perdem lentamente sua carga. Assim, o DIMM requer atualizações periódicas na memória, ou seja, seu conteúdo precisa ser lido e gravado periodicamente.

Se isso não acontecer, a memória perde seu conteúdo. Esta atualização de memória acontece por hardware, principalmente no controlador de memória da placa-mãe / cpu.

Eles também têm outra característica: ler o conteúdo da memória limpa o condensador (eles são muito pequenos, porque é a única maneira de integrar o maior número possível em um chip de memória). Assim, depois de cada lembrança, seu conteúdo deve ser escrito de volta.

Problemas relacionados a este mecanismo de atualização não são detectados pelo memtest.

Embora seja detectável se o memtest funcionasse em um método, ele verifica metade da memória e deixa a outra metade em paz, alternando entre eles apenas após um longo atraso. Mas não foi implementado no memtest até agora.