Existem muitos problemas com o Elastic Search e, pesquisando rapidamente, você pode encontrar alguns. Mas o maior problema no uso de alta CPU pode ser causado devido à falta de controle sobre o uso do cache. Por favor, abaixo para referências:
Estamos executando um cluster de pesquisa elástico de 4 nós / máquina em 12 núcleos, 96 GB de RAM, 4 unidades de disco giratório. sob operação normal, a maior parte da utilização da cpu é do utilizador e cerca de 5-10%. A cada poucos dias, um dos usos da CPU da máquina fica atrelado a 80-100% e é tudo usuário e sistema - a espera na verdade diminui. Primeiro pensamos que era um problema específico do elasticsearch, mas depois de uma depuração extensa, não parece ser assim:
Se pararmos o processo por cerca de uma hora e depois reiniciarmos o processo (não a máquina), o problema desaparece e as coisas funcionam bem por alguns dias.
Também notamos que, durante o problema, os testes de cópia de disco são muito lentos. Com o processo ativo, mas ocioso (não indexando / pesquisando dados) ou logo após o processo ter parado, a cópia de um arquivo de 1GB via dd acontece a cerca de 18MB / s na máquina problemática, mas a 490MB / s quando estiver saudável. Curiosamente, percebemos usando dstat que a cópia lenta levou cerca de 25 segundos antes de fazer qualquer i / o e, em seguida, levou mais 30 segundos para concluir. A saída strace não parece ser significativamente diferente.
Alguma ideia de que testes adicionais poderíamos realizar?
Processos que usam muita CPU devem aparecer no topo, como sugerido por Ian Macintosh, mas como é baseado em amostragem da tabela de processos em um ciclo regular, essa visibilidade pode depender de quanto tempo esses processos são executados.
Os utilitários de contabilidade GNU também podem ser muito úteis para esse tipo de coisa. (package = 'acct' em sistemas baseados em Debian, ou 'psacct' em baseados em redhat). Eu rotineiramente executo em cima e tenho o pacote de contabilidade em ( accton on ) para a maioria dos servidores.
Depois de ativar a coleta de dados contábeis, as estatísticas são mantidas sobre o uso da CPU de cada processo que é executado, juntamente com o início e a execução da execução. Isso pode ser muito útil quando vários processos de curta duração estão consumindo sua cpu, o que é difícil de ver com sobre, strace, etc (embora strace possa ser mais útil com o -f ou -ff flag). É menos útil quando você tem processos com uma vida útil muito maior do que o pico da CPU, mas, nesses casos, deve dar o que você deseja. lastcomm é provavelmente a ferramenta que você deseja para acessar as estatísticas coletadas.
embora muito útil, strace apenas informa sobre as chamadas do sistema. Se você tem algo usando CPU intensamente, mas não chamando o sistema, ele não aparecerá. Por vezes, o ltrace pode ser útil para isso, mas, novamente, apenas se a atividade relevante ocorrer dentro de uma chamada de biblioteca e nem sempre é o caso.
Ferramentas como strace e ltrace, e talvez até mesmo um depurador como o gdb, só entram em ação depois que você identificou o processo que está consumindo a CPU, e não parece que você já tenha percebido isso. Neste ponto, o topo e o lastcomm são provavelmente o caminho a seguir.
Que testes adicionais você poderia fazer?
(Falta alguma informação como o% de CPU do sistema é quando indexado vs% de CPU do usuário) mas verifique qual porcentagem de CPU é IRQ, apenas no caso de isso levar a algum lugar.
Assumindo que a% de CPU do sistema é razoavelmente alta e não é IRQ, você pode querer verificar a memória. Uma ferramenta útil para uma visão geral está no topo, ele deve informar se algo como varredura de página ou roubo de página está causando isso porque você está sob strong pressão de memória.
Suponho que você excluiu a troca como um problema.
Como o about dá uma visão abrangente do estado da máquina, é muito útil para lidar com o estado geral. Isso ajudaria a comparar em cima de um sistema operacionalmente correto com um que também está se comportando mal.
Se a anormalidade somente for% de CPU do usuário e o próprio sistema estiver operando corretamente, então você provavelmente estará lidando com um bug de software e terá que reverter para os autores para obter ajuda - ou alterar como você está usando para evitar acionar qualquer bug que você encontrou. Apenas verifique se você não está lidando com seu próprio bug - ou seja, você está chamando mal ou em um loop ou algo dessa natureza. Eu já vi isso algumas vezes.
Em resumo, entre na memória, irq, swap etc e veja se você pode excluí-los - sugiro uma comparação rápida entre o comportamento normal & comportamento aberrante e destacar itens críticos.