Não foi possível alterar vm.max_map_count para elasticsearch

14

Pré-história

Eu tenho elasticsearch e SugarCRM7 rodando no CentOS 6.5. Todos os dias enfrento o mesmo problema: erro java outOfMemory. Isso acontece devido ao pequeno valor vm.max_map_count, 65530 somente quando 262144 é recomendado.

Problema

O problema é que vm.max_map_count parece imutável:

  1. Alterando sob raiz

    sudo sysctl -w vm.max_map_count=262144

    retorna

    erro: permissão negada na chave 'vm.max_map_count'

    Enquanto

    ps aux | grep java

    Retorna apenas o processo grep

  2. Alterando na inicialização do elasticsearch

    sudo service elasticsearch start

    Também retorna erro

    erro: permissão negada na chave 'vm.max_map_count'

    Iniciando elasticsearch: [OK]

  3. Mudanças manuais via arquivo (truque sujo-sujo):

    sudo vi /proc/sys/vm/max_map_count

    Também não funciona:

    "/ proc / sys / vm / max_map_count" [somente leitura] 1L, 6C

    - INSERT - W10: Aviso: Alterando um arquivo somente leitura

    E45: a opção 'somente leitura' está definida (adicione! Para substituir)

    "/ proc / sys / vm / max_map_count" E212: Não é possível abrir o arquivo para gravação

    Enquanto

    ls -la /proc/sys/vm/ | grep max_map_count

    Devoluções

    -rw-r - r-- 1 raiz raiz 0 abr 10 09:36 max_map_count

    (Mas acho que isso pode ser normal para o linux falando sobre o diretório / proc)

Então, como posso alterar o valor dessa variável? Reiniciar a pesquisa elástica todas as noites não é uma boa ideia ... Ou, pelo menos, alguém sabe por que esse erro ocorre?

java centos6 elasticsearch sugarcrm Valentina
fonte
3
Que tipo de máquina é essa? Virtual? Se sim, que tipo de virtualização é usada? Observe que algumas virtualizações, por exemplo, os contêineres OpenVZ impõem limitações ao seu contêiner e não permitem que você "ajuste" o kernel e outras coisas de baixo nível.
Miroslav Koškár 10/04
@MiroslavKoskar Eu não sei, infelizmente. Como posso descobrir isso?
Valentina
@MiroslavKoskar Esqueci de mencionar - a máquina é virtual, é claro
Valentina
1
Como descobrir? Bem, onde está hospedado? Deve ser bastante óbvio, porque geralmente faz parte do seu contrato com o seu provedor de hospedagem. Se ainda estiver em dúvida, entre em contato com o suporte do provedor de hospedagem, IMHO, que é o melhor lugar para começar (já que geralmente faz parte do acordo e algo pelo qual você provavelmente está pagando).
Miroslav Koškár 12/04/2015
@MiroslavKoskar bem, o provedor respondeu sem mencionar a tecnologia que eles não podem me ajudar com esse problema (isso é bastante razoável). Obrigado pela sua ajuda.
Valentina

Respostas:

13

você está quase lá. Não importa se é uma máquina virtual ou física, essas configurações são sempre variáveis.

Eu vou mostrar 3 métodos.

Algumas pré-informações:

1) É melhor executar como root, se possível.

2) / proc no unix não é um sistema de arquivos real, é um sistema de arquivos do kernel na memória, mas parece um sistema de arquivos em disco normal. Você pode chamá-lo de 'sistema de arquivos falso' ou 'sistema de arquivos especial'; não é possível editar esses arquivos falsos com o vi ou qualquer outro editor, porque eles não são arquivos, apenas se parecem com arquivos. Eu fiquei com o mesmo problema anos atrás.

Mas é simples alterar seus valores, basta exigir outro tipo de 'mecânica' para editá-los.

Vou explicar: Primeiro, precisa ser root: (o sudo funciona em algumas distros, mas não em outras distros como você tentou, esse primeiro método é universal e funciona em qualquer Linux, macOS ou qualquer sistema baseado em Unix Espero que você tenha acesso à senha root.

Prossiga no prompt:

    $ su root

Digite a senha root.

Agora você é root, vamos verificar o valor atual de: / proc / sys / vm / max_map_count

    $ cat /proc/sys/vm/max_map_count  
    65536

Vamos mudar isso:

    echo 262144 > /proc/sys/vm/max_map_count

Vamos verificar:

    cat /proc/sys/vm/max_map_count
    262144

Está feito! E já está aplicado e funcional. Alterando os valores de qualquer pseudo-arquivo em / proc, as configurações ficam ativas instantaneamente. Mas eles não persistem após uma reinicialização. Você pode brincar com valores e medir as alterações de desempenho no elasticsearh ou em qualquer outro aplicativo ou métrica do sistema. Vá alterando seu sistema, escrevendo os valores em algum papel, mantenha os melhores valores. Em qualquer erro, reinicie e todos voltarão aos valores originais e inicie novamente até que todos os valores desejados sejam ideais. Há muitos parâmetros ajustáveis ​​de disco e memória em / proc. E eles fazem uma enorme diferença e ganho de desempenho se você os ajustar bem (e tiver tempo para isso). Voce está no caminho certo.

Quando satisfeitos, vamos torná-los permanentes:

Primeiro método:

usando /etc/rc.local

    vi /etc/rc.local

coloque todos os parâmetros dentro do arquivo rc.local, exemplo:

    echo 220000000 > /proc/sys/vm/dirty_background_bytes
    echo 320000000 > /proc/sys/vm/dirty_bytes
    echo 0 > /proc/sys/vm/dirty_background_ratio
    echo 0 > /proc/sys/vm/dirty_ratio
    echo 500 > /proc/sys/vm/dirty_writeback_centisecs
    echo 4500 > /proc/sys/vm/dirty_expire_centisecs
    echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
    echo 10 > /proc/sys/vm/swappiness
    echo never > /sys/kernel/mm/transparent_hugepage/enabled
    echo never > /sys/kernel/mm/transparent_hugepage/defrag
    echo 120 > /proc/sys/net/ipv4/tcp_keepalive_time
    echo 0 > /proc/sys/vm/zone_reclaim_mode
    echo deadline > /sys/block/sda/queue/scheduler
    echo 8 > /sys/class/block/sda/queue/read_ahead_kb
    echo 1048575 > /proc/sys/vm/max_map_count

saia do vi editor salvando o arquivo.

Esses parâmetros serão definidos a cada reinicialização, APÓS o início de todos os serviços init, imediatamente antes do prompt de login aparecer.

(o arquivo /etc/rc.local é executado após todos os serviços linux de inicialização, pode não funcionar se o elasticsearch iniciar antes dele como um serviço, mas esse método pode ser útil em outra configuração, se você precisar no futuro, ou você pode usar assim colocando-os dentro do script init do elasticsearch, porque o script init é executado como root; portanto, é a mesma sintaxe acima para usar dentro dos scripts init)

Você também pode copiá-los agora e colá-los para alterações instantâneas. Os parâmetros acima são válidos, ajustados e em execução no meu servidor apache cassandra. Se desejar, tente-os como um ponto de partida para ajustar o seu.

Segundo método para torná-los permanentes:

Os parâmetros agora serão definidos ANTES de qualquer serviço de inicialização no linux.

Edite /etc/sysctl.conf , coloque parâmetros dentro

 vm.max_map_count=1048575
 vm.zone_reclaim_mode=0
 vm.dirty_background_bytes=220000000
 vm.dirty_background_ratio=0
 vm.dirty_bytes=320000000
 vm.dirty_ratio=0
 vm.swappiness=10

continue com os outros, salve o /etc/sysctl.conf , reinicie o servidor para aplicar as alterações ou execute: sysctl -p para aplicar as alterações sem a reinicialização. Eles serão permanentes nas reinicializações.

Dois métodos acima são os mais comuns. Há outro, e pode funcionar para você, é usando sudo , quase como se estivesse fazendo:

ao invés de: 

  sudo sysctl -w vm.max_map_count=262144

experimentar: 

  echo 262144 | sudo tee /proc/sys/vm/max_map_count

Funciona no ubuntu.

Verificar: 

   user@naos:~$ cat /proc/sys/vm/max_map_count
   262144

Espero ter ajudado de alguma forma, pelo menos, dando as três opções diferentes para lidar com o problema, já que há quase um ano sua pergunta;)

Atenciosamente, Rafael Prado

user62739
fonte
3
Eles já fizeram isso e falhou.
Michael Hampton
1
Oi Michael, sim, você está certo. Eu entendi a princípio que o problema estava relacionado ao sistema operacional CentOS e às permissões de usuário unix, então segui essa linha na minha resposta. Porém, informações mais recentes colocam o foco do problema no OpenVZ "host", o que limita algumas configurações. Meu conhecimento é sobre Centos e VmWare, mas não sobre o OpenVZ.
user62739
4

Eu acho que sua "máquina virtual" é na verdade um contêiner OpenVZ (que você pode verificar isso executando virt-what).

Nesse caso, você não pode alterar o vm.max_map_countsysctl ou muitos outros. Os valores são fixos.

Esse é um problema conhecido da elasticsearch ( edição # 4978 ). Não é apenas a Elasticsearch. Sabe-se que os aplicativos Java apresentam um desempenho ruim em vários provedores OpenVZ, principalmente porque os hosts geralmente são mal ajustados e não há nada que você possa fazer sobre isso. Um comentarista sobre esse assunto ecoou exatamente qual seria minha recomendação:

joshuajonah comentou em 20 de outubro de 2015
This is insane. Acho que vou mudar para um KVM VPS.

Michael Hampton
fonte