Há duas configurações simples no nível do sistema operacional Linux que as pessoas parecem estar deixando de configurar corretamente em seus sistemas de produção. Elas estão documentadas em outro lugar, mas continuam aparecendo e parece que precisam de uma rápida revisão aqui. Não se trata de uma configuração super secreta ou de itens mágicos de correção de desempenho, mas são coisas que, em um banco de dados do Couchbase de produção, devem ser configuradas corretamente conforme abaixo e incorporadas ao sistema/processo que você usa para inicializar os nós que usa para o Couchbase. Eles ajudam no desempenho do memcached e no reequilíbrio do desempenho e, em alguns casos, em problemas de estabilidade.

Certifique-se de testá-los primeiro em um ambiente de teste antes de passar para a produção com eles, obviamente.

A troca deve ser desativada

Este é bastante simples se você conhece o sistema de memória virtual do Linux. Os níveis de troca informam ao subsistema de memória virtual o quanto ele deve tentar trocar para o disco. O problema é que o sistema tentará trocar itens na memória mesmo quando houver bastante RAM disponível para o sistema. O padrão do sistema operacional geralmente é 60, o que é um pouco agressivo, na minha opinião. Você pode ver qual é o valor definido para o seu sistema executando o seguinte comando:

cat /proc/sys/vm/swappiness

Como o Couchbase é ajustado para realmente operar na memória o máximo possível, você pode ganhar ou, no mínimo, não perder desempenho simplesmente alterando o valor de swappiness para 0. Você pode ganhar ou, no mínimo, não perder desempenho simplesmente alterando o valor de swappiness para 0. Em termos não técnicos, isso diz ao subsistema de memória virtual do sistema operacional para não trocar itens da RAM para o disco, a menos que seja realmente necessário, o que, se você tiver dimensionar seus nós corretamenteA troca não deve ser necessária. Para definir isso, execute o seguinte processo: use o sudo ou torne-se root se você estiver no oeste selvagem.

# Defina o valor para o sistema em execução
sudo sh -c 'echo 0 > /proc/sys/vm/swappiness'

# Backup do sysctl.conf
sudo cp -p /etc/sysctl.conf /etc/sysctl.conf.date +%Y%m%d-%H:%M

# Defina o valor em /etc/sysctl.conf para que ele permaneça após a reinicialização.
sudo sh -c 'echo "" >> /etc/sysctl.conf'
sudo sh -c 'echo "#Set swappiness to 0 to avoid swapping" >> /etc/sysctl.conf'
sudo sh -c 'echo "vm.swappiness = 0" >> /etc/sysctl.conf'

Certifique-se de que você tenha ou modifique o processo de criação dos sistemas operacionais para fazer isso. Isso é especialmente importante para nuvens públicas/privadas, onde é muito fácil criar novas instâncias. Você precisa fazer isso parte do seu processo de compilação para um nó do Couchbase.

Desativar o Transparent Huge Pages (THP)

A partir da versão 6 do Red Hat Enterprise Linux (RHEL), o que também inclui o CentOS 6 e 7, um novo método padrão de gerenciamento de páginas enormes foi implementado no sistema operacional. O Ubuntu também tem essa configuração a partir da versão 12.02, portanto, também precisará ser alterado. O THP combina páginas de memória menores em páginas enormes sem que os processos em execução saibam. A ideia é reduzir o número de pesquisas necessárias no TLB e, portanto, aumentar o desempenho. Ele traz uma abstração para automação e gerenciamento de páginas enormes, basicamente. A engenharia do Couchbase determinou que, sob algumas condições, O Couchbase Server pode ser afetado negativamente por atrasos graves na alocação de páginas quando o THP está ativado. Portanto, a Couchbase recomenda que o THP seja desativado em todos os nós do Couchbase Server

Confirme se as configurações do sistema operacional precisam ser desativadas

Verifique o status do THP emitindo os seguintes comandos:

cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

Em algumas variantes do Red Hat ou do Red Hat, talvez você precise fazer isso:

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
cat /sys/kernel/mm/redhat_transparent_hugepage/defrag

Se, em um ou ambos os arquivos, a saída for semelhante a essa, você precisará do procedimento abaixo:

[sempre] madvise nunca

 

Copiar o script de inicialização

O script de inicialização foi projetado para garantir que as alterações sejam feitas ao mesmo tempo em que o Couchbase é carregado na reinicialização.

#!/bin/bash
### BEGIN INIT INFO
# Fornece: disable-thp
# Início obrigatório: $local_fs
# Parada obrigatória:
# Início padrão: 2 3 4 5
# Parada padrão: 0 1 6
# Descrição resumida: Desativar THP
# Descrição: desativa o Transparent Huge Pages (THP) na inicialização
### END INIT INFO

 

caso $1 em
  início)
    if [ -d /sys/kernel/mm/transparent_hugepage ]; then
       echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
       echo 'never' > /sys/kernel/mm/transparent_hugepage/defrag
    elif [ -d /sys/kernel/mm/redhat_transparent_hugepage ]; then
      echo 'never' > /sys/kernel/mm/redhat_transparent_hugepage/enabled
      echo 'never' > /sys/kernel/mm/redhat_transparent_hugepage/defrag
   mais
      retorno 0
   fi
   ;;
esac

 

Como registrar o código no sistema operacional

Faça o seguinte:

Crie um arquivo com o código acima

$ sudo vi /etc/init.d/disable-thp

 

Chmod o arquivo para ser executável

$ sudo chmod 755 /etc/init.d/disable-thp

 

Execute-o para que ele entre em vigor agora mesmo

$ sudo service disable-thp start

 

Certifique-se de que o script de inicialização seja iniciado na inicialização

Variantes da Red Hat:

$ sudo chkconfig disable-thp on

 

Ubuntu:

$ sudo update-rc.d disable-thp defaults

 

Teste o processo

Verifique o status do THP emitindo os seguintes comandos:

cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

 

Em algumas variantes do Red Hat ou do Red Hat, talvez você precise fazer isso:

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
cat /sys/kernel/mm/redhat_transparent_hugepage/defrag

 

Para ambos os arquivos, o resultado deve ser o seguinte:

sempre madvise [nunca]

 

Observação: Há uma maneira diferente de fazer isso que você encontrará em outro lugar e que edita o arquivo /etc/grub.conf. Meu problema com isso é que, no futuro, ele seria eliminado a cada atualização do kernel. O que proponho é mais fácil de gerenciar a longo prazo e fácil de colocar em algo como um módulo Puppet ou uma receita Chef para anexar ao final do rc.local quando você inicializa um nó.

O THP é um ótimo recurso para algumas coisas, mas causa problemas com aplicativos como o Couchbase. Ele não é o único com esse problema. Se você pesquisar na Internet por páginas enormes transparentes, há vários problemas documentados de outros fornecedores de bancos de dados e aplicativos sobre isso. Até que se encontre algo que funcione com isso, é melhor desativar o THP.

Autor

Postado por Kirk Kirkconnell, engenheiro de soluções sênior, Couchbase

Kirk Kirkconnell foi engenheiro de soluções sênior da Couchbase, trabalhando com clientes em várias capacidades para ajudá-los a arquitetar, implantar e gerenciar o Couchbase. Sua experiência é em operações, hospedagem e suporte de infraestruturas de aplicativos e bancos de dados em larga escala.

9 Comentários

  1. \"sudo echo > file\" não faz o que você pensa que faz.

    \"sudo sh -c \'echo > file\'\" (ou echo | arquivo sudo tee) faz isso.

    1. Bem visto. Corrigido. Obrigado!

  2. Embora eu concorde que o swappiness deva ser baixo, talvez você queira fazer alguns testes com o kernel 2.6.32. Houve uma modificação na forma como o vm.swappiness=0 se comporta, e vi relatos de que o kernel eliminou serviços como o MySQL devido ao OOM, mesmo quando parte da RAM ainda estava sendo usada para o cache de arquivos. Eu executo com vm.swappiness=1 em vez de 0, o que ainda significa que o kernel não deve trocar a menos que seja realmente necessário... mas pode fazê-lo se for preciso, em vez de eliminar processos.

    1. Legal. Vou dar uma olhada. Por acaso você tem um link disponível sobre as alterações na versão 2.6.32 relacionadas a isso? Se não tiver, não se preocupe. Vou procurar por ele.

      1. Não tenho certeza se você ainda precisa disso, mas encontrei uma publicação no blog que resume a modificação e as mudanças de comportamento resultantes: http://www.percona.com/blog/20

        Caso essa postagem desapareça em algum momento, aqui estão algumas das informações da postagem:

        Informações de confirmação do código do kernel:
        commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd
        Autor: Satoru Moriya
        Data: Tue May 29 15:06:47 2012 -0700
        mm: evite a troca com swappiness==0

        Informações do changelog do RHEL:
        * Mon Aug 27 2012 Jarod Wilson [2.6.32-303.el6]

        - [mm] evitar a troca com a troca==0 (Satoru Moriya) [787885]

        1. Estive verificando internamente e parece haver algum debate sobre esse assunto. Pelo que estou ouvindo, a recomendação ainda é definir swappiness=0, embora tenhamos clientes que optaram por 1. Vou me aprofundar e fazer mais alguns testes.

          1. Ouvi dizer que sim.
            É principalmente uma pergunta do tipo \"como você quer que ele falhe e com que rapidez\", suponho, e não é uma situação que as pessoas devam encontrar com frequência. Esperamos que qualquer pessoa tenha alarmes relacionados ao uso de RAM disparando bem antes de o kernel enfrentar a opção de trocar ou matar o Couchbase :)

  3. Hi,

    Segui sua orientação e meu arquivo rc.local tem a seguinte aparência:

    ————————————————————–

    #!/bin/sh -e
    #
    # rc.local
    #
    # Esse script é executado no final de cada nível de execução multiusuário.
    # Certifique-se de que o script \"exit 0\" em caso de sucesso ou qualquer outro valor# em caso de erro.
    #
    # Para ativar ou desativar esse script, basta alterar a execução
    Bits #.
    #
    # Por padrão, esse script não faz nada.
    [ -x /sbin/initctl ] && initctl emit -no-wait google-rc-local-has-run || true
    saída 0

    if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
    echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
    fi

    if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
    echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
    fi

    ——————————————————————————-

    Agora eu sou muito inexperiente no Linux, mas a saída 0 não significa que ele nunca chegará aos testes transparent_hugepage? Por favor, me ajude a entender/corrigir isso.

    Atenciosamente,
    Davi

Deixar uma resposta