Alguns sistemas Linux ficam muito lentos quando o Redis está carregando um grande conjunto de dados

14

Eu recebi um relatório de um usuário do Redis, e não tenho certeza do que responder, já que não sou especialista na área de Linux e seu agendador, no entanto, nós (como o projeto Redis) precisamos descobrir esse tipo de problemas, especialmente no futuro, como com o Redis Cluster, teremos muitas instâncias do Redis sendo executadas ao mesmo tempo em uma única caixa. Então estou pedindo ajuda aqui.

Problema:

  • Kernel: "Linux redis1 2.6.32-305-ec2 # 9-Ubuntu SMP Qui Abr 15 08:05:38 UTC 2010 x86_64 GNU / Linux"
  • bastante RAM livre, nenhum outro processo fazendo E / S significativa.
  • Importante , executado em uma instância grande do EC2, não em um servidor real. Eu nunca vi algo assim em um ambiente não virtualizado. A instância do EC2 era: "Instância extra-grande de memória alta 17,1 GB de memória, 6,5 ECU (2 núcleos virtuais com 3,25 Unidades de computação EC2 cada), 420 GB de armazenamento de instância local, plataforma de 64 bits" .

Basicamente, uma vez que você reinicie uma grande instância do Redis, o sistema ficará tão lento que você não poderá mais digitar no shell. Quando o Redis carrega uma instância, ele usa 100% da CPU (carrega os dados o mais rápido possível) e lê o arquivo dump.rdb sequencialmente. AE / S não é particularmente alta, pois o carregamento é limitado pela CPU, não pela E / S.

Por que, na Terra, uma caixa com dois processadores e muita memória RAM, sem trocas de coisas no disco, deve basicamente parar de funcionar com essa carga de trabalho?

Tenho a impressão de que isso tem muito a ver com o fato de ser uma instância do EC2, tão relacionada à tecnologia de virtualização usada, pois carrego todos os tempos Redis 24 GB de conjuntos de dados na minha caixa sem nenhum problema (mesmo com outras instâncias do Redis executando com alta carga).

Obrigado por qualquer dica!

Salvatore

Editar : adicionando alguns comentários que recebi do twitter:

de @ezmobius: @antirez primeira coisa a fazer é tentar a partir de / mnt ou as unidades efêmeras locais para ver se a sua descamação EBS, 2 é ter certeza de que não é a "penalidade primeira escrita" (google) e se é então que você precisa dd 0's através do disco primeiro.

de @dvirsky: @antirez Estou executando muitas instâncias de redis exatamente nesses nós ec2. Eu notei alguma desaceleração no bgsave, mas não esse fenômeno.

    
por antirez 08.04.2011 / 18:58

3 respostas

4

A saída do 'topo' pode gerar algumas pistas. Há um campo perto do canto superior esquerdo rotulado "% roubado", que reflete a quantidade de CPU de hardware desviada para outros convidados na mesma caixa física. Eu vi esses tipos de lentidão quando o hipervisor decide alocar mais CPU para outro convidado, especialmente quando estou realizando uma tarefa de uso intensivo de CPU de longa duração.

Não tenho certeza se esse é seu problema ou não, mas vale a pena verificar.

    
por 08.04.2011 / 19:06
2

Eu tive o mesmo problema em uma instância do EC2. Provavelmente não está relacionado ao Redis - ocorre quando há um alto IO em andamento (por exemplo, quando o redis está carregando um arquivo de despejo).

Veja este tópico nos fóruns da Amazon: link

Eu experimentei diferentes kernels / images e agora ele roda bem (em um antigo kernel 2.6.21).

    
por 08.04.2011 / 19:44
2

Você deve verificar o roubo da CPU ( xx.x%st no lado direito da linha cpu) que top mostra quando você experimenta a carga de 100% e o shell congelado. Steal representa quanto de seus ciclos reais de CPU são roubados de sua máquina por um hypervisor e dados a outra máquina. O roubo de CPU é relevante apenas em ambientes virtualizados. Eu tive esse problema exato com micro instâncias e que basicamente tornou minha instância inutilizável por cerca de 1 hora ou mais (até que minha tarefa terminou ofc) se fazendo tarefas intensivas da CPU.

Você pode encontrar mais sobre esse assunto lendo este post sobre Ramblings de Greg . Embora se você tomar a palavra de Greg, isso deve estar acontecendo apenas em micro-instâncias.

    
por 08.04.2011 / 20:39