Comandos lentos no Redis Redis blocking commands (single-threaded)
ID da causa db-redis-block · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O Redis processa um comando de cada vez, então um único comando lento bloqueia todas as requisições que vêm atrás.
Por quê Busca completa com KEYS durante a operação, ou leitura ou exclusão de uma vez de rankings e listas com milhões de elementos → Efeito Até esse comando terminar, todas as outras requisições esperam (de dezenas de ms a alguns segundos) → Na tela Engasgos simultâneos nos recursos que usam sessão, ranking e cache; login lento
Aleatoriamente, de vez em quando, Em intervalos regulares
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Trocar KEYS por SCAN, dividir chaves grandes, apagar com UNLINK (exclusão em segundo plano), espalhar expirações concentradas no mesmo segundo.
O que fazer (Equipe de infraestrutura)
Monitorar o log de comandos lentos (SLOWLOG), bloquear comandos perigosos como KEYS nos servidores de produção, verificar chaves grandes periodicamente, desligar o THP e garantir folga de memória para o fork, fazer o salvamento RDB e AOF na réplica.
Números de referência
Comandos comuns levam menos de 1 ms. Lidar com milhões de elementos de uma vez pode levar de centenas de ms a alguns segundos.
No gráfico
Picos aleatórios · Latência de resposta do Redis, comandos lentos
Onde olhar
Ver com SLOWLOG GET os comandos que passaram do slowlog-log-slower-than e, depois de ligar o monitor de latência (desligado por padrão) com CONFIG SET latency-monitor-threshold, ver a latência por evento, como fork e expire-cycle, com LATENCY LATEST e LATENCY DOCTOR. Conferir também o tempo de fork e as chaves grandes com o latest_fork_usec do INFO e o redis-cli --bigkeys
Confirma se
No horário da parada, o SLOWLOG tem KEYS ou comandos que manipulam uma chave grande inteira, ou o LATENCY registra no mesmo horário eventos de fork ou expire-cycle de dezenas de ms ou mais
Descarta se
SLOWLOG e LATENCY vazios, mas lento só do lado do servidor do jogo: rede ou espera dentro do servidor do jogo (o SLOWLOG mede só o tempo de execução do comando, sem o tempo de troca de dados com o cliente)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O Redis também para no momento em que duplica o processo (fork) para gerar o arquivo de salvamento (snapshot RDB) ou reescrever o AOF. Nos servidores atuais, isso leva cerca de 10 ms a cada 1 GB de memória, ou seja, uns 300 ms para 30 GB. Com páginas grandes (THP) ligadas, cada escrita depois do fork copia uma página grande inteira (copy-on-write), o que aumenta muito a pausa e o uso de memória; por isso, em geral se desliga o THP e se deixa bastante folga de memória. Quando muitas chaves expiram no mesmo segundo, o Redis também para por um instante para apagá-las.
Fontes
Diagnosing latency issuesRedis Uma única thread processa as requisições em sequência, e um comando lento bloqueia todas as seguintes; trocar KEYS por SCAN; o fork medido em servidores físicos e VMs modernas leva cerca de 9–13 ms a cada 1 GB; o THP causa picos de latência e de memória por causa da cópia depois do fork; expiração em massa no mesmo segundo causa paradas
KEYSRedis Usar com extremo cuidado em produção, pois pode arruinar o desempenho em bancos grandes (40 ms para 1 milhão de chaves em um notebook de entrada)
UNLINKRedis Exclusão assíncrona que desvincula a chave na hora e recupera a memória em outra thread
SLOWLOGRedis Log de comandos lentos que registra os comandos que passam do slowlog-log-slower-than; o tempo de execução não inclui o I/O de troca de dados com o cliente
Redis latency monitoringRedis latency-monitor-threshold com padrão 0 (desligado), LATENCY LATEST e LATENCY DOCTOR, registro da latência por evento, como fork e expire-cycle
INFORedis latest_fork_usec: duração do último fork (microssegundos)
Redis CLIRedis --bigkeys: varre o keyspace e encontra chaves grandes