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

11

Pré-história

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

Problema

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

  1. Mudando na raiz

    sudo sysctl -w vm.max_map_count=262144
    

    retorna

    error: permission denied on key 'vm.max_map_count'

    Enquanto

    ps aux | grep java
    

    Retorna apenas o processo do grep

  2. Mudando na inicialização do elasticsearch

    sudo service elasticsearch start
    

    Retorna o erro também

    error: permission denied on key 'vm.max_map_count'

    Starting elasticsearch: [ OK ]

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

    sudo vi /proc/sys/vm/max_map_count
    

    Também não funciona:

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

    -- INSERT -- W10: Warning: Changing a readonly file

    E45: 'readonly' option is set (add ! to override)

    "/proc/sys/vm/max_map_count" E212: Can't open file for writing

    Enquanto

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

    Retorna

    -rw-r--r-- 1 root root 0 Apr 10 09:36 max_map_count

    (Mas eu 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 o elasticsearch toda noite não é uma boa idéia ... Ou pelo menos alguém pode saber porque esse erro acontece?

    
por Valentina 10.04.2015 / 09:52

3 respostas

11

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

Mostrarei 3 métodos.

Alguma pré-informação:

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 ser como um sistema de arquivos em disco normal. Você pode chamá-lo de 'sistema de arquivos falso' ou 'sistema de arquivos especial', você não pode editar esses arquivos falsos com o vi ou qualquer outro editor, porque eles não são arquivos, eles apenas se parecem com arquivos. Eu fiquei com o mesmo problema anos atrás.

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

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

Continue no prompt:

    $ su root

Digite a senha do 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. Ao alterar os valores de qualquer pseudo arquivo sob / proc, as configurações se tornam ativas instantaneamente. Mas eles não persistem após uma reinicialização. Você pode brincar com valores e medir mudanças de desempenho em elasticsearh ou qualquer outra aplicação ou métrica do sistema. Vá tunning seu sistema, escrevendo os valores em algum papel, mantenha os melhores valores. Em qualquer erro, reinicialize e todos eles retornarão aos valores originais e inicie novamente até que todos os valores desejados sejam ideais. Há muitos parâmetros de disco e memória sintonizáveis em / proc. E eles fazem uma grande diferença e ganho de desempenho se você ajustá-los bem (e ter tempo para isso). Você está no caminho certo.

Quando estiver satisfeito, 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 editor vi salvando o arquivo.

Esses parâmetros serão definidos a cada reinicialização, DEPOIS de todos os serviços de inicialização terem sido iniciados, logo antes do prompt de login ser exibido.

(o arquivo /etc/rc.local é executado após todos os serviços de inicialização do linux, ele pode não funcionar se o elasticsearch for iniciado antes dele como um serviço, mas esse método pode ser útil em outro configuração se você precisar no futuro, ou você pode usar assim colocando-os dentro do seu script de inicialização elasticsearch, porque o script init é executado como root, então é 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, experimente-os como 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 os 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 /etc/sysctl.conf , reinicie o servidor para aplicar as alterações ou execute: sysctl -p para aplicar as alterações sem reinicializar . 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 você estava fazendo:

em vez de:

  sudo sysctl -w vm.max_map_count=262144

tente:

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

Funciona no Ubuntu.

Verifique:

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

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

Atenciosamente, Rafael Prado

    
por 20.08.2016 / 09:07
4

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

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

Este é um problema bem conhecido com o elasticsearch ( issue # 4978 ). Não é apenas o Elasticsearch. É sabido que os aplicativos Java têm um desempenho ruim em vários provedores do OpenVZ, principalmente porque os hosts são frequentemente mal ajustados e não há nada que você possa fazer a respeito. Um comentarista dessa questão ecoou exatamente qual seria minha recomendação:

joshuajonah commented on Oct 20, 2015
This is insane. I guess I'm going to change over to a KVM VPS.

    
por 20.08.2016 / 09:28
0

Você pode seguir as instruções oficiais:

sysctl -w vm.max_map_count=262144

Para tornar a mudança permanente, atualize a configuração vm.max_map_count em /etc/sysctl.conf

Consulte o link

    
por 17.01.2018 / 11:51