Estou vendo um consumo de memória muito alto na minha instância de elasticsearch.
Eu configurei ES_HEAP_SIZE = 4g.
O comando de partida para ES começa com:
/usr/lib/jvm/java-8-oracle/jre/bin/java -Xms4g -Xmx4g
Até aí tudo bem.
Mas estou vendo mais de 7 GB de consumo de memória RSS.
Aqui está a saída / proc / status: link
Mas quando executo jstat -gc tudo parece normal, vejo cerca de 3,7 GB no OC e 270 MB no EC ( link ).
Esta é uma saída pmap ordenada: link
Você tem alguma ideia, por que o consumo de memória é tão alto?
Além disso, o ES é executado em um servidor virtual no OpenVZ.
O problema provavelmente está na JVM e, se você iniciar várias instâncias do ES, examine-o com o /java-mission-control-1998576.html "> link ou jconsole link . Isso lhe dará uma ideia do motivo pelo qual está consumindo tanta memória.
Tenha em mente que a JVM usa GC e outros processos fora da memória heap. Inicie o ES com -xms 1024 e deixe crescer. Também, até onde eu me lembro, o java pega -xms, -xmx argumentos como MB no como GB, só para estar no lado seguro, converter tudo em MB.
Use jvisualvm para ver o consumo de heap (e muito mais), é a ferramenta oficial de depuração e criação de perfil para java, instalada por padrão com java.
Anexe-o ao processo elasticsearch, verifique se os sinalizadores -Xmx e -Xms têm o valor correto e olhe para os gráficos. É muito simples.
O processo java deve ter 4 GB de heap em todos os momentos porque você definiu o heap mínimo e máximo. Ele deve consumir 4-4,5 GB no sistema, pois há alguma sobrecarga para gerenciar o heap que não é contabilizado como parte do heap.
De qualquer forma, o java não permite que o processo use mais heap do que o configurado (isso mataria o processo se tentasse). É provável que exista outra coisa usando a memória do seu computador. Use top ou htop para ver outros processos em execução.
O que você define com ES_HEAP_SIZE é o tamanho de heap Java disponível para o programa que está sendo executado na JVM. Além disso, a JVM tem sua própria sobrecarga, mas a sobrecarga do GC (seus dados não são contabilizados como heap Java) e cada encadeamento em execução precisa de memória para sua pilha (quantos encadeamentos você tem e qual é o tamanho da pilha?). O ElasticSearch provavelmente não usa o armazenamento fora do heap, mas é sempre algo que deve ser observado.
Já ouvi falar de casos em que a alteração do alocador de memória ajudou a reduzir o footprint total da JVM (jemalloc vs. glibc malloc). Finalmente, eu tentaria uma versão da JVM diferente (mais recente?) Ou um algoritmo de GC diferente, se possível ...
Tags java openvz elasticsearch