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

Recebi um relatório de um usuário Redis e não tenho certeza do que responder, pois não sou especialista na área de Linux e seu agendador, no entanto, nós (como o projeto Redis) precisamos entender esse tipo de problema especialmente no futuro, como no Redis Cluster, teremos muitas instâncias do Redis executando 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 15 abr 08:05:38 UTC 2010 x86_64 GNU / Linux"
• abundância de RAM livre, nenhum outro processo com E / S significativa.
• Importante , executando em uma grande instância do EC2, não em um servidor real. Eu nunca vi algo assim em um ambiente não virtualizado. A instância do EC2 foi: "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 da instância local, plataforma de 64 bits" .

Basicamente, quando você reinicia uma grande instância do Redis, o sistema fica tão lento que você não pode 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. A E / S não é particularmente alta, pois o carregamento é vinculado à CPU e não à E / S.

Por que diabos uma caixa com duas CPUs e muita RAM, sem coisas trocadas no disco, deveria basicamente parar de trabalhar 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, relacionada à tecnologia de virtualização usada, pois carrego o tempo todo os conjuntos de dados Redis de 24 GB na minha caixa sem nenhum problema (mesmo com outras instâncias do Redis executando com alta carga).

Obrigado por qualquer dica!

Salvatore

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

from @ezmobius: @antirez A primeira coisa a fazer é experimentá-lo no / mnt ou nas unidades efêmeras locais para ver se a sua escamação do EBS é a segunda, para garantir que não seja a "primeira penalidade de gravação" (pesquise no google) e, se for, você precisa dd 0 através do disco primeiro.

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

A saída de 'top' pode render algumas pistas. Há um campo próximo ao canto superior esquerdo chamado '% roubado', que reflete a quantidade de CPU de hardware desviada para outros convidados na mesma caixa física. Eu já vi esse tipo de lentidão quando o hipervisor decide alocar mais CPU para outro convidado, especialmente quando estou executando alguma tarefa demorada e que exige muita CPU.

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

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

Dê uma olhada neste tópico nos fóruns da amazon: https://forums.aws.amazon.com/thread.jspa?messageID=215406

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

Você deve verificar o roubo de CPU ( xx.x%stno lado direito da linha da CPU) que topaparece quando você experimenta a carga de 100% e o shell congelado. Roubar representa quanto dos seus ciclos reais de CPU são roubados da sua máquina por um hipervisor 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) ao executar tarefas intensivas da CPU.

Você pode encontrar mais informações sobre esse tópico lendo este post em Greg's Ramblings . Embora se você seguir a palavra de Greg, isso deve acontecer apenas em micro instâncias.