Estou lidando com um problema há algumas semanas, o que resulta em um após a VM ser executada por alguns dias.
"lento" significa que as operações ligadas à CPU demoram mais tempo do que antes e que essas operações parecem se acumular com o tempo. Recarregar as assinaturas do ClamD, por exemplo, leva ~ 35 segundos e 100% em um núcleo normalmente, o que aumenta para 1 minuto ou mais sem qualquer outro carregamento, mas pode levar 10 ou 15 minutos com alguma outra carga. Essa outra carga pode ser consultas de banco de dados por algum aplicativo da web, criando 100% de carga em um núcleo em si já. Parece que sem o problema, ambas as operações simplesmente processam tão rápido quanto a CPU é capaz, enquanto que, com o problema, ambas as tarefas ligadas à CPU ficam mais lentas em si mesmas e, ao mesmo tempo, aumentam a carga geral no sistema. Todas as outras pequenas operações como htop ou outras criam uma carga alta anormal também. Além disso, processos como o ClamD com 100% de carga em um núcleo normalmente são mostrados como criação de uma carga de 150% ou mais. O que, em teoria, e como as pessoas do ClamAV disseram, é impossível para recarregar assinaturas porque isso simplesmente não é multi-threaded. Assim, parece que alguma sobrecarga é introduzida, o que reduz o desempenho geral do sistema. Ao mesmo tempo, nem a VM hospeda a si mesma ou outras VMs no mesmo host sofrem com problemas de desempenho.
Isso aconteceu com um guest-OS do UB 14.04 LTS no passado e também com o 16.04 LTS após uma nova instalação incluindo a recriação da VM e tal. Acho que consegui rastrear isso para uma diferença: Se a VM for usada com 48 GB de RAM, o problema ocorrerá após alguns dias de execução, se for usado com apenas 6 GB de RAM, não faz. Tenho certeza de que a quantidade de RAM realmente é a única diferença em ambos os casos, a carga de trabalho testada é a mesma e fornecida por alguns testes que executam automaticamente usando o Jenkins e as atualizações de assinatura da ClamD. É muito provável que o problema não ocorra com pelo menos 8 GB de RAM também, porque eu tenho outra VM com essa memória não mostrando o problema, mas não sei atualmente qual é o limite superior de RAM até o momento problema ocorre. É muito demorado testar isso, porque o problema não existe desde o começo, começa a acontecer em algum momento.
Meu servidor é um HP DL380 G7 com 2 Intel Xeon X5675 @ 3,07 GHz com 144 GB de RAM, distribuído uniformemente por todos os soquetes e slots de RAM. Ele executa o UB 16.04 LTS, hospeda as VMs no ZFS e a VM testada possui 8 vCPUs e 48 GB de RAM ou 6 atribuídos. Os recursos do servidor devem ser mais do que suficientes para as minhas necessidades, o primeiro usado G6 foi um pouco mais lento com um pouco menos de RAM e não mostrou esses problemas. E sem o problema ocorrer com 48 GB de RAM, a VM se comporta como esperado também. Tenho quase certeza de que não há troca ou supercomprometimento de memória no host:
top - 11:49:38 up 28 days, 13:54, 1 user, load average: 0.26, 0.33, 0.35
Tasks: 904 total, 1 running, 899 sleeping, 0 stopped, 4 zombie
%Cpu(s): 0.1 us, 0.5 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 14853158+total, 5032192 free, 13115475+used, 12344644 buff/cache
KiB Swap: 5852156 total, 5852144 free, 12 used. 11533812 avail Mem
Atualmente estou olhando para NUMA vs. "Node Interleaving", mas estou certo de que o NUMA está habilitado. Além disso, pelo que li, o impacto no desempenho pode ser em torno de 20% ou até 40%, mas não tão pesado que alguns processos como conectar-se ao banco de dados acabam totalmente. Eu também li que na maioria dos casos, um não deve simplesmente lidar com os específicos do NUMA, mas manter os padrões do sistema operacional e deixar que o kernel decida onde programar qual encadeamento, etc. Eu não preciso do último desempenho de qualquer maneira , é só que atualmente as coisas ficam inaceitáveis lentamente depois de algum tempo.
$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22
node 0 size: 72477 MB
node 0 free: 14758 MB
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23
node 1 size: 72572 MB
node 1 free: 11046 MB
node distances:
node 0 1
0: 10 20
1: 20 10
$ dmesg | grep -i numa
[ 0.000000] NUMA: Node 0 [mem 0x00000000-0xdfffffff] + [mem 0x100000000-0x121fffffff] -> [mem 0x00000000-0x121fffffff]
[ 0.000000] mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
$ sysctl -a | grep numa_
kernel.numa_balancing = 1
kernel.numa_balancing_scan_delay_ms = 1000
kernel.numa_balancing_scan_period_max_ms = 60000
kernel.numa_balancing_scan_period_min_ms = 1000
kernel.numa_balancing_scan_size_mb = 256
Além do NUMA, eu li sobre o hugepages no Linux e as grandes páginas do VirtualBox, mas pelo que eu entendi, não usar nenhum dos dois deve ter um impacto negativo tão dramático como o que estou vendo. O VirtualBox fala sobre um benefício de desempenho de ~ 5% usando páginas maiores e enquanto as páginas de entrada não são definidas explicitamente no meu host, elas são usadas e disponíveis usando "páginas enormes e transparentes" do que eu vejo em /proc/vmstat .
O que me faz pensar é que 48 GB de RAM não tem muita memória, eu li outros usuários com problemas apenas depois de mais de 128 GB foram atribuídos e os desenvolvedores informaram que eles testado com sucesso com 1 TB de RAM.
Você tem alguma ideia do que poderia criar o problema aqui?