Estou tentando fazer alguns testes com o ZingVM da Azul, que precisa pré-alocar uma grande quantidade de memória RAM.
O problema é, no meu servidor (rodando o Cent OS 5.8) que tem 16GB de RAM, mais de 8GB serão usados logo após a reinicialização ... assim (eu reinicializo o servidor, ssh login nele, e execute free -m de uma vez):
total used free shared buffers cached
Mem: 16048 8281 7767 0 1 19
-/+ buffers/cache: 8260 7788
Swap: 18047 0 18047
Obviamente, os buffers e o cache não contribuem para o RAM usado de 8GB. Este é um servidor de aplicativos que executa o Apache Tomcat todos os dias (para testes), e tenho certeza de que o Tomcat não será iniciado automaticamente.
Eu tentei descobrir qual processo está usando uma quantidade tão grande de memória com top , mas apenas para descobrir que o processo usando o RES-top usa apenas 4460k ...
No entanto, tenho outro servidor (com o Cent OS 5.8) executando o mysql. O uso de memória desse servidor de banco de dados é normal. Agora estou testando o ZVM no servidor de banco de dados, e com Zing alocando 65% de RAM na inicialização, após uma nova reinicialização, o free -m mostra:
total used free shared buffers cached
Mem: 16048 10942 5105 0 3 55
-/+ buffers/cache: 10883 5165
Swap: 18047 0 18047
Então ... Se ignorarmos os 65% de 16GB - cerca de 10GB - usados pelo Zing, a memória usada após a reinicialização deve ser apenas vários MBs.
Agora estou apenas testando se consigo usar o Tomcat trabalhando no ZingVM. Então eu preciso executar testes reais em outros dois servidores Cent OS e, infelizmente, esses dois servidores têm o mesmo problema. Ou seja, temos 4 servidores e 3 servidores têm esse problema.
Qual pode ser o motivo desse problema? Posso resolvê-lo sem reinstalar o sistema operacional nessas máquinas?
Atualização:
aqui está o que o zing-system-tool reporta quando tento configurá-lo para usar 75% (seu valor padrão) da memória. Exatamente o mesmo padrão de saída quando especifico 85%.
Fatal error: Not enough free memory (memoryForAzulBytes (12620660736) > MemFree (8142327808)).
zing-memory: ERROR: Configure pmem failed
Fatal error: os::safeSystem: command '/sbin/service zing-memory restart' failed.
E aqui está uma alocação bem-sucedida no servidor de banco de dados (eu especifiquei 68% desta vez, e o valor antigo é 65%; o ZST liberará a memória reservada por si):
Info: azulPmemPages: 5456.
INFO: az_pmem_reserve_pages (num2mPages 5456) succeeded
INFO: az_pmem_fund_transfer (to 7, from 0, bytes 11442061312) succeeded
INFO: az_pmem_fund_transfer (to 1, from 7, bytes 570425344) succeeded
INFO: az_pmem_fund_transfer (to 3, from 7, bytes 570425344) succeeded
INFO: az_pmem_fund_transfer (to 0, from 7, bytes 10301210624) succeeded
Info: You can now start Java processes up to -Xmx9824m or -Xmx9g.
Info: Azul pmem initialized successfully.
zing-memory: INFO: start successful
zing-memory: INFO: restart successful
Atualização 2:
Eu vi isso em / proc / meminfo no servidor problemático:
HugePages_Total: 4096
HugePages_Free: 4096
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
enquanto no servidor de banco de dados, é tudo 0. Poderia ser esse o motivo da memória usada?
OK, eu percebi:
Veja minha atualização 2 na pergunta. Essa é a razão.
A página de acesso é reservada; a menos que especificado, os aplicativos não o usarão. Então o ZST não pode alocar a memória.
Quando eu defino a Hugepage para zero, a memória é liberada de uma vez e o ZST aloca a memória com êxito.
Teste slabtop no servidor problemático e veja se o kernel aloca enormes quantidades de RAM por algum motivo. Por exemplo, o XFS pode alocar muita memória para seu cache sem estar visível em colunas de buffers / cache (embora o XFS libere a memória quando necessário).