Desaceleração computacional do servidor quando a RAM é usada extensivamente

Question

Eu tenho problema com a lentidão do servidor em um cenário muito específico. Os fatos são:

• 1) Eu uso o aplicativo computacional WRF (Weather Research and Forecast)
• 2) Eu uso Dual Xeon E5-2620 v3 com 128GB de RAM (arquitetura NUMA - provavelmente relacionado ao problema!)
• 3) Eu corro o WRF com mpirun -n 22 wrf.exe (tenho 24 núcleos lógicos disponíveis)
• 4) Eu uso o Centos 7 com o kernel 3.10.0-514.26.2.el7.x86_64
• 5) Tudo funciona bem em termos de desempenho computacional até que uma coisa aconteça:
• 5a) cache do arquivo linux obtém alguns dados, ou
• 5b) Eu uso tmpfs e preencho com alguns dados

No cenário 5a ou 5b, meu WRF começa a desacelerar de repente e às vezes chega a ser ~ 5x mais lento que o normal.

• 6) RAM não é trocado, não está nem perto de acontecer, eu tenho cerca de 80% de RAM livre no pior cenário!
• 7) vm.zone_reclaim_mode = 1 no /etc/sysctl.conf parece ajudar um pouco a atrasar o problema no cenário 5a
• 8) echo 1 > / proc / sys / vm / drop_caches resolve o problema completamente no cenário 5a, restaura o desempenho do WRF para velocidade máxima, mas apenas temporário até que o cache de arquivos obtenha dados novamente, então eu uso este comando no cron (não se preocupe, está tudo bem, eu usar computador apenas para WRF e não precisa de cache de arquivos para funcionar com desempenho total)
• 9) mas, o comando acima ainda não faz nada no cenário 5b (quando eu uso o tmpfs para arquivos temporários)
• 10) O desempenho é restaurado no cenário 5b somente se eu esvaziar manualmente o tmpfs
• 11) Não é problema de WRF ou mpi
• 12) Isso acontece apenas neste tipo de computador e eu administro muitos deles para o mesmo / similar (WRF). Apenas este tem arquitetura NUMA completa, então eu suspeito que isso tenha algo com ele
• 13) Eu também suspeito que o kernel do RHEL tem algo com isso, mas não tenho certeza, não tentei reinstalar em diferentes distros ainda
• 14) uma opção numd e numactl para invocar o mpirun como "numactl -l", não fez nenhuma diferença

Deixe-me saber se você tem alguma ideia para tentar evitar essas lentidões.

Uma ideia vem depois de seguir alguns links "Relacionados" sobre esta questão. As páginas enormes transparentes podem ser uma fonte deste problema? Alguns artigos sugerem que o THP não funciona bem em sistemas NUMA.

    

Answer 1

Sugiro ativar o serviço NumaD:

yum install numad
systemctl enable numad
systemctl start numad

A numd deve ser capaz de cuidar da localização da memória automaticamente. A situação como processo é executada na CPU do primeiro nó NUMA, no entanto, os dados estão no local da RAM ao segundo nó NUMA, não devem mais acontecer (a menos que a quantidade de memória necessária seja maior que a capacidade da RAM local para o único nó NUMA).

Sugiro também configurar o serviço ajustado com perfil, que corresponde melhor ao seu cenário de uso. Você teria que medir as diferenças e escolher o melhor (ou você pode criar algumas personalizadas).

Talvez eu tenha encontrado o motivo do comportamento estranho em seu nó. Eu procurei por mpirun e encontrei a página man:

link

Está escrito:

Quick Summary

If you are simply looking for how to run an MPI application, you probably want to use a command line of the following form: % mpirun [ -np X ] [ --hostfile ] This will run X copies of in your current run-time environment (if running under a supported resource manager, Open MPI’s mpirun will usually automatically use the corresponding resource manager process starter, as opposed to, for example, rsh or ssh, which require the use of a hostfile, or will default to running all X copies on the localhost), scheduling (by default) in a round-robin fashion by CPU slot. See the rest of this page for more details.

Please note that mpirun automatically binds processes as of the start of the v1.8 series. Three binding patterns are used in the absence of any further directives:

Bind to core: when the number of processes is <= 2

Bind to socket: when the number of processes is > 2

Bind to none: when oversubscribed

If your application uses threads, then you probably want to ensure that you are either not bound at all (by specifying --bind-to none), or bound to multiple cores using an appropriate binding level or specific number of processing elements per application process.

No seu caso, com n = 22, não há vinculação aplicada e os segmentos podem ser realocados. Você pode tentar ligação de CPU externa (como com taskset). Você terá que experimentar.