Quanto tempo leva para executar o memtester em um servidor com 3 TB de RAM?

Uma execução do memtest86+ levou cerca de 3 dias em um desses hosts (v6.10). Provavelmente ajuda que o memtest seja multithread, como o artigo de Shipolev menciona.

No mesmo servidor, uma execução de memtester 2700g 3(versão 4.5.1) ainda estava no primeiro loop de 3 após execução por 21 dias de tempo de relógio de parede. Estava usando 100% de um núcleo constantemente.

Este era um R930 com CPU Intel E7-8880 v4 (176 núcleos) e 96x32 GB de RAM DDR4 a 2400 MHz.

Concluindo, reiniciar a máquina e executar o memtest86+ usual continua sendo a melhor chance. As cargas de trabalho precisam ser interrompidas ou movidas para outro lugar para que tais investigações aconteçam.

Não é uma opção testar preventivamente a memória dessa forma, então provavelmente valerá a pena conduzir o teste de memória somente após alguns erros terem sido detectados pelo kernel ou a quantidade de travamentos da JVM for tão grave que as cargas de trabalho tiveram que ser interrompidas ou movidas para outro lugar já. Usar o memtester ainda pode ser útil em alguns casos onde a quantidade de memória a ser testada é limitada e o acesso físico ou uma reinicialização são proibitivamente caros.

Exemplo de log

$ free -g
              total        used        free      shared  buff/cache   available
Mem:           3023          76        2934           0          11        2933
Swap:            55           1          54

$ time nice -n 10 sudo memtester 2700g 3
memtester version 4.5.1 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 2764800MB (2899102924800 bytes)
got  2764800MB (2899102924800 bytes), trying mlock ...locked.
Loop 1/3:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones        : ok
  Walking Zeroes      : setting  11^C

real    30966m20.456s
user    27802m43.020s
sys     3084m14.099s

Não há uma resposta geral possível: isso dependerá da RAM e do controlador de memória da CPU, e há várias ordens de magnitude de diferença que você pode esperar do hardware de servidor disponível atualmente.

Geralmente, testar memória física testando memória virtual do espaço do usuário é... hm, essa é uma má ideia por design. Você gastaria mais tempo estressando a lógica de paginação no seu kernel, a MMU da sua CPU, as múltiplas camadas de coerência de cache em máquinas multi-core (o que uma máquina de 3 TB provavelmente é) do que realmente faria interagindo com RAM física, e se você não for cuidadoso ao fazer isso da maneira que sua CPU é otimizada para acessar a memória (em máquinas x86_64/AVX2 e posteriores, mm256_stream_*vs carregamento/armazenamentos clássicos vs...) você obteria outro fator, geralmente na ordem de 5×, na perda de desempenho.

Então, você ir em memtest86+vez disso (o que realmente coloca este Q/A fora do tópico deste site, você não acha?) foi a jogada certa, mais ou menos (eu não acho que ele realmente saiba do cache e da topologia de coerência da sua máquina, então ele não pode realmente testar em paralelo bem). Mas honestamente: por quê? Até mesmo aquele blog, que assume máquinas muito menores (uma RAM de 128 GB parece ser grande para elas), diz, OK, você começa com RAM ECC. E de jeito nenhum você tem um único nó conectado a 3 TB de RAM que não seja RAM ECC. E se você tem RAM ECC, então você terá um contador de quantos erros ele teve que corrigir. Inversões de bits na RAM são esperadas, e em 3 TB de RAM, você pode ter certeza de que pelo menos uma ocorreu - mas é o trabalho do ECC converter o erro físico de volta para os dados corretos, para que você tenha memória confiável.

Mas é claro que, embora o ECC corrija a maioria dos erros, também pode (má sorte) acontecer que os erros sejam tão graves que o resultado pareça dados válidos (ou algo que pode ser mais facilmente "corrigido" para os dados válidos errados do que para os dados corretos). Então, se você sabe qual geração de RAM sua máquina usa e que tipo de ECC ela usa, você pode fazer inferências do contador de erros ECC corrigíveis para a contagem de erros corrigidos incorretamente. Isso é muito melhor no uso prático do que executar uma verificação de memória sintética – que pode ou não ver coisas como efeitos vizinhos (pense em coisas como Rowhammer), enquanto os contadores ECC realmente observam o que dá errado durante o uso. Um pico em erros ECC corrigíveis seria motivo para investigação.

Vindo de uma direção diferente: se você tem memória ECC, você deve ter contadores de erros corrigidos e não corrigidos. No RHEL8 e RHEL9, instale o rasdaemonpacote, e então ras-mc-ctl --error-countlistará as contagens de erros registradas pelo hardware nesta inicialização:

# ras-mc-ctl --error-count
Label                   CE      UE
mc#0csrow#1channel#1    0       0
mc#0csrow#0channel#0    0       0
…

Além disso, você pode iniciar o rasdaemonserviço na inicialização, e ele colocará os erros detectados em um banco de dados que você pode consultar com ras-mc-ctl --errors. Isso permite que você compare os timestamps de erros de memória conhecidos com os timestamps de travamentos e erros de kernel.

Finalmente, rasdaemona configuração do /etc/sysconfig/rasdaemonpermite que você o configure para dizer ao kernel para desligar páginas ruins da memória se elas tiverem muitos Erros Corrigidos em um período de tempo; se você configurar isso e vir muitas páginas offline, você sabe que tem memória defeituosa. Isso também lhe dá uma chance de manter o sistema funcionando com memória falha, reduzindo a capacidade de memória para remover a RAM defeituosa.