Tamanho da memória virtual grande da ElasticSearch JVM

Question

Estou executando uma JVM para suportar o ElasticSearch. Ainda estou trabalhando no dimensionamento e ajuste, então deixei o tamanho de heap máximo da JVM no padrão de 1 GB do ElasticSearch. Depois de colocar dados no banco de dados, descubro que o processo da JVM está mostrando 50 GB em SIZE em top output. Parece que isso está realmente causando problemas de desempenho no sistema; outros processos estão tendo problemas para alocar memória.

Ao perguntar à comunidade ElasticSearch, eles sugeriram que é "apenas" o armazenamento em cache do sistema de arquivos. Na minha experiência, o cache do sistema de arquivos não aparece como memória usada por um processo específico. É claro, eles podem estar falando de algo diferente do cache do sistema de arquivos do sistema operacional, talvez algo que a própria JVM ou ElasticSearch esteja fazendo no topo do sistema operacional. Mas eles também disseram que seria lançado se necessário, e isso não parecia estar acontecendo.

Então, alguém pode me ajudar a descobrir como ajustar a JVM, ou talvez o próprio ElasticSearch, para não usar tanta RAM.

O sistema é o Solaris 10 x86 com 72 GB de RAM. A JVM é "Java (TM) SE Runtime Environment (build 1.7.0_45-b18)".

    

Answer 1

Tenho certeza de que a resposta que você obteve da comunidade ElasticSearch está relacionada ao ARC (Adaptive Replacement Cache) do ZFS. Isso obviamente pressupõe que seu sistema de arquivos é ZFS?

No ZFS, o ARC potencialmente ocupará toda a RAM disponível no host a menos de 1 Gb. Portanto, em ferramentas host do ZFS, como top , algumas vezes, a RAM física fica perto do limite, mesmo que não esteja. Isso é por design. O ARC liberará automaticamente a memória para processos que precisam de memória. A memória que o ARC usa conta como memória do kernel, então você não pode realmente vê-lo em uma saída do processo.

Na maioria dos sistemas Solaris que eu vejo diariamente, o consumo físico de RAM é de cerca de 90%. Isto não é porque eles são muito utilizados, é o ZFS que pega RAM não utilizada para seu próprio propósito. Não se assuste com isso. Como o ARC é parte do kernel, ele pode liberar memória para processos que precisam na velocidade da luz, por assim dizer. Portanto, embora você possa, eu normalmente não vejo razão em limitar o tamanho do ZFS ARC. É melhor deixar o ZFS fazer o seu trabalho.

Então, se estamos falando sobre o ZFS, então sim, o armazenamento em cache do sistema de arquivos não aparece como consumo de memória em um processo individual. Você precisará executar algo como:

echo "::memstat" | mdb -k

para revelar como sua memória é realmente usada. A linha "Anon" abrange todos os processos de uso do usuário que você vê em, e. prstat output.

A outra coisa para você saber é como a JVM trabalha em termos de alocação de memória e liberação de memória. A JVM retém a memória do sistema operacional, já que precisa dela apenas restrita pelo parâmetro de linha de comando da JVM -Xmx . A questão em aberto é como (se alguma vez) a JVM irá liberar memória de volta ao sistema operacional se não precisar mais dele? Você descobrirá que é muito difícil encontrar informações sobre esse assunto. Parece depender de qual coletor de lixo é usado. Como é difícil obter informações precisas sobre este assunto (não sei por que realmente) sua melhor opção é assumir que a JVM é extremamente relutante em liberar memória de volta ao sistema operacional. Em outras palavras: se você permitir que um processo da JVM capture 50 GB de memória, é melhor que você esteja em condições de fazer isso permanentemente em vez de assumir que isso é apenas uma explosão.

Então, se você quiser limitar a quantidade de memória que o processo do ElasticSearch pode consumir, será necessário examinar os Parâmetros da linha de comandos da JVM , em particular a opção -Xmx .