Saltar para o conteúdo 
O Slow Log do Redis mostra-me exatamente quais os comandos que bloqueiam o thread do servidor e quanto tempo demora a sua execução, na ordem das microsegundos, o que me permite eliminar de forma específica as fontes de latência. Com valores-limite robustos, uma exportação organizada e métricas correlacionadas, otimizo o Desempenho sustentável.
Pontos centrais
Antes de aprofundar o assunto, defino os pontos-chave mais importantes, para poder avançar de forma orientada para os objetivos. Concentro-me em configurações claras, padrões recorrentes e contramedidas eficazes. Além disso, presto atenção à relação com o contexto do cliente e com o ambiente do sistema. É assim que consigo uma abordagem consistente Análise sem ruído. Depois, aplico os resultados diretamente em ajustes no código, no modelo de dados e na monitorização.
- Limiar e escolher um comprimento de log adequado
- Modelos sobre Tempo, identificar comandos e clientes
- Executar comandos lentamente Alternativas substituir
- Modelo de dados e Armazenamento em cache tonificar
- Entradas lentas Monitorização integrar
Slow Log: breve explicação do funcionamento
Entendo o Slow Log como uma visão centrada na pura Tempo de execução de um comando no modo single-thread do Redis. O servidor regista automaticamente uma entrada assim que a duração exceder o valor-limite definido em «slowlog-log-slower-than», em microssegundos. Cada registo fornece-me o ID, o timestamp Unix, o tempo de execução, o comando com argumentos, o IP/porta do cliente e, opcionalmente, o nome do cliente. O Slow Log omite deliberadamente a E/S de rede e a transmissão da resposta, o que me permite ver o tempo real de bloqueio da thread. É precisamente esta separação que me ajuda a distinguir claramente as causas lógicas da latência de rede ou do cliente e a Causa delimitar melhor.
Configuração: limiar e comprimento do registo
Para começar o dia de forma produtiva, coloco o Limiar geralmente para 10 000 microssegundos (cerca de 10 ms); nos testes, reduzo-o temporariamente para captar detalhes mais precisos. Controlo o número de entradas guardadas com o `slowlog-max-len`, normalmente entre 128 e 4096, para que os picos de carga permaneçam bem visíveis. Altero ambos os valores no ficheiro `redis.conf` ou em tempo de execução com o comando `CONFIG SET`, o que me permite janelas de diagnóstico flexíveis. Antes de testes de carga de grande envergadura, reduzo o valor-limite; após a conclusão, volto a aumentá-lo para um valor realista de produção. Desta forma, mantenho o registo conciso, sem perder informações importantes Sinais para perder.
| Configuração/Comando | Significado | Valor prático |
|---|---|---|
| mais lento do que o slowlog | Valor-limite em microssegundos para as entradas | Produção: 10 000 µs; Teste: 1 000–5 000 µs |
| slowlog-max-len | Número máximo de registos guardados | 128–4096 entradas, consoante o volume |
| SLOWLOG GET N | Mostra os últimos N registos | N = 10–100 para verificações pontuais |
| SLOWLOG LEN | Devolve o comprimento atual do registo | Verificar regularmente |
| SLOWLOG RESET | Limpa o registo | Exportar/guardar antes |
Ler o Slow Log no dia-a-dia
No dia-a-dia, recupero os registos mais recentes com o comando SLOWLOG GET e verifico, com o comando SLOWLOG LEN, em que medida as instruções lentas se estão a acumular, antes de, se necessário, esvaziar o registo com o comando SLOWLOG RESET. Uma exportação antes do reset evita que eu perca dados valiosos História perco, especialmente quando pretendo comparar tendências ao longo de vários dias. Em configurações de cluster, incluo todas as instâncias e réplicas, uma vez que o Slow Log é específico de cada instância e, caso contrário, ficariam pontos cegos. Para análises estruturadas, associo as entradas a informações do cliente, como IP, porta e nome definido, para poder identificar inequivocamente a fonte no código da aplicação. Além disso, consulto as estatísticas INFO para avaliar frequências e latências no contexto da utilização global.
Dos acontecimentos aos padrões: análise sistemática
Começo por analisar os comandos que mais se destacam e que apresentam um elevado Tempo de execução e, em seguida, verifico com que frequência ocorrem no total nessa instância. Um comando que raramente ultrapassa o limite incomoda menos do que um que está ligeiramente acima do limiar, mas que é executado mil vezes por minuto. Os aglomerados temporais durante tarefas Cron, cópias de segurança ou picos de tráfego indicam-me se a causa são picos de trabalho ou rotinas da aplicação. Através do comando `INFO commandstats`, obtenho contexto sobre o número de chamadas e as durações médias, o que posso consultar facilmente no artigo INFO commandstats aprofundar. Associo os nomes de clientes identificados na CLIENT LIST a serviços ou microsserviços, o que me permite atribuir a responsabilidade e a Otimização planeie de forma específica.
Estratégias de otimização: comandos e modelo de dados
Substituo comandos dispendiosos, como o KEYS, em grandes volumes de dados pelo SCAN com cursores personalizados, para evitar bloqueios e melhorar a Latência reduzir. Quando os scripts Lua demoram demasiado tempo a executar-se, divido a lógica em vários passos mais pequenos ou recorro a dados pré-agregados. Muitas vezes, os tempos de execução prolongados são um sintoma do modelo de dados: divido listas, conjuntos ou hashes muito grandes, utilizo índices adicionais ou tipos de dados mais adequados. No caso de cálculos dispendiosos e recorrentes, armazeno os resultados em cache mais próximo da aplicação e invalido-os de forma controlada, em vez de forçar a sua reconstrução repetidamente. Abordo as configurações erradas típicas e os anti-padrões de forma prática através de Configurações incorrectas típicas juntos, para que eu possa corrigir mais rapidamente os erros evitáveis e os Eficiência aumentar.
Contexto do cliente e código da aplicação
No código, reduzo as idas e voltas através do pipelining e do agrupamento, o que me permite reduzir o tempo de execução puro Hora do servidor Embora não altere nada, reduzo significativamente a latência observada por cada chamada. Os parâmetros das entradas do Slow Log mostram-me onde surgem loops desnecessários ou acessos repetidos. Asseguro que os clientes atribuam nomes significativos através do CLIENT SETNAME, para que a atribuição seja imediatamente clara para a equipa. Distribuo as cargas de escrita identificando teclas de atalho, diversificando os padrões de acesso e verificando as estratégias de TTL. Durante fases de migração ou ativação de funcionalidades, observo de forma específica as entradas dos caminhos afetados, para identificar os impactos atempadamente e a qualidade para garantir.
Recursos, topologia e fontes de latência
Nem toda a lentidão se deve a comandos ineficientes; por isso, verifico os picos de utilização da CPU, os estrangulamentos de memória e a latência da rede em paralelo com os Entradas no Slow Log. Uma distribuição inadequada dos shards, um número insuficiente de réplicas ou percursos interzonas longos aumentam a duração percebida. Verifico ainda as configurações de RDB/AOF e as tarefas em segundo plano que sobrecarregam temporariamente o processo do servidor. Sob carga elevada, considero opções de escalabilidade, desde que o modelo de dados já esteja otimizado e a escolha dos comandos seja adequada. Só a correlação com as métricas do sistema me permite ter uma visão clara Causa-efeito‑As correntes são visíveis.
Integrar o Slow Log no Monitoring
Um painel dedicado mostra-me a evolução do comprimento dos registos, o número de comandos lentos por serviço e dados correlacionados, como a utilização da CPU e da memória. Integro os dados do Slow Log nos pipelines de observabilidade existentes, criando assim um fluxo contínuo de Monitorização. Nas interfaces gráficas, filtro por comandos, horários e clientes para isolar mais rapidamente as anomalias. Para fluxos de trabalho práticos, recorro a ferramentas com visualizações de registos de lentidão, ambiente de trabalho e funções de exportação, tal como as que utilizo no Guia do RedisInsight descrevo. Desta forma, encurto significativamente o percurso do diagnóstico e aumentei a relevância do Métricas.
Guia prático: passo a passo
Primeiro, certifico-me de que os parâmetros «slowlog-log-slower-than» e «slowlog-max-len» estão definidos de forma adequada, para não gerar ruído nem perder dados relevantes Sinais perco. Em seguida, leio os registos mais recentes, guardo-os e identifico comandos suspeitos, tendo em conta a frequência e a duração. Na etapa seguinte, analiso intervalos de tempo, associo nomes de CLIENTES e procuro padrões em parâmetros recorrentes. A partir daí, deduzo medidas concretas no código, no modelo de dados e nos conceitos de cache. Por fim, integro a análise no meu sistema de monitorização permanente, para que possa detetar tendências numa fase precoce e Regressões impedir.
Dados empíricos e critérios de afinação
Um valor inicial de 10 ms como limiar funciona bem em muitos ambientes de produção, enquanto valores mais baixos podem ser úteis em testes pormenores fornecer. Ajusto o comprimento do log de forma a que reflita padrões típicos diários ou semanais, sem desperdiçar espaço de armazenamento. Estabeleço uma linha de base, documento as distribuições típicas de comandos e fico atento a alterações graduais. Após as implementações, consulto deliberadamente o «Slow Log» para detetar atempadamente se novas funcionalidades estão a criar caminhos de latência indesejados. Esta disciplina permite-me obter conclusões fiáveis sobre quando devo fazer ajustes e como devo Desempenho manter a longo prazo.
Limites e orientações de interpretação do Slow Log
Tenho em conta que o Slow Log mede apenas o tempo de execução puro na thread do servidor. Os tempos de espera na fila de comandos, os custos do handshake TLS ou o transporte de respostas de grande dimensão através da rede não aparecem nesse registo. Da mesma forma, os argumentos dos comandos no Slow Log são limitados por razões de memória e podem ser encurtados, razão pela qual considero os parâmetros apenas como uma indicação e não como a verdade absoluta. Como o registo funciona com base em limiares, obtenho uma amostra dos casos mais lentos e não uma distribuição completa. Por isso, complemento as análises com percentis de latência provenientes da monitorização e, quando necessário, utilizo o monitor LATENCY integrado (limiar definido através de latency-monitor-threshold) para detetar picos esporádicos.
Características específicas dos clusters e da replicação
Em configurações de cluster, verifico se os comandos lentos se concentram em slots ou shards específicos. As operações entre slots (por exemplo, MGET em chaves sem hash tag) provocam erros ou desvios e geram idas e voltas desnecessárias, que não são visíveis no Slow Log, mas aumentam a latência percebida. Os reequilíbrios, os failovers e as replicações de recuperação afetam a carga do sistema: comandos como o WAIT podem demorar intencionalmente mais tempo até que as confirmações sejam recebidas. Nas réplicas em modo de espera, aplicam-se perfis de acesso diferentes; nessas instâncias, analiso as entradas do Slow Log separadamente, porque as cargas de leitura, os esforços de sincronização e os processos em segundo plano diferem entre si. Para um diagnóstico preciso, exporto o Slow Log de cada instância e correlaciono os carimbos de data/hora em todos os nós.
Persistência, bifurcações e comportamento da memória
Estou atento aos instantâneos RDB e às reescritas AOF: ao bifurcar o processo do Redis, o „Copy-on-Write“ pode levar a um aumento temporário das necessidades de memória e a picos de utilização da CPU, o que, por sua vez, prolonga o tempo de execução dos comandos. As configurações AOF (por exemplo, `appendfsync`) influenciam as latências de gravação; „everysec“ é geralmente um bom compromisso, enquanto «always» aumenta a durabilidade, mas pode favorecer a ocorrência de picos. Além disso, tenho em conta a desfragmentação ativa da memória, as evicções e o processamento de chaves expiradas. Chaves individuais de grande dimensão (por exemplo, hashes com dezenas de milhares de campos) provocam pausas percetíveis nos ciclos de expiração ou durante as eliminações. Com opções «lazyfree» (por exemplo, «lazyfree-lazy-eviction»), alivio a carga da thread principal, permitindo que a libertação de grandes estruturas seja realizada de forma assíncrona, desde que o perfil da carga de trabalho o permita.
Comandos de bloqueio, Multi-Key e de script
Faço uma distinção entre comandos com complexidade linear (O(N)) e variantes logarítmicas ou constantes. Os comandos SORT, SUNIONSTORE, ZUNIONSTORE ou HGETALL, quando aplicados a estruturas de grande dimensão, aparecem frequentemente no Slow Log. Embora o EVAL/EVALSHA sejam atómicos e práticos, podem ocupar a thread do servidor durante muito tempo devido a loops internos; neste caso, são preferíveis etapas mais pequenas e bem coordenadas. Comandos de bloqueio como BLPOP ou XREAD BLOCK bloqueiam principalmente o cliente, não o thread do servidor — mas tornam-se críticos quando combinados com estruturas de dados muito grandes. Durante a análise, evito padrões MATCH amplos sem lógica de índice e ajusto o COUNT de forma a manter a carga controlável; o SCAN protege contra bloqueios totais, mas não é um passe livre para pesquisas não direcionadas.
Exportação, automatização e preparação de dados
Para garantir a reprodutibilidade das análises, exporto regularmente o Slow Log e padronizo o formato. Incluo nas entradas o nome do cliente, os utilizadores (ACL) e as etiquetas de serviço, para que a atribuição de responsabilidade seja inequívoca. Um fluxo de trabalho simples através do Shell ajuda-me nas exportações pontuais:
# Exportação semelhante a JSON das últimas 500 entradas
redis-cli SLOWLOG GET 500 > slowlog.raw
# Exemplo em CSV (ID; data e hora; duração em µs; comando; cliente)
# Nota: os argumentos podem estar abreviados no Slow Log
redis-cli --raw SLOWLOG GET 200 | awk '
BEGIN{FS="\n"; OFS=";"}
/1\)/{id=$2} /2\)/{ts=$2} /3\)/{dur=$2} /4\)/{cmd=$0; gsub(/^[^"]*"/,"",cmd); gsub(/"[^$]*/,"",cmd)} /5\)/{client=$0}
/5\)/{print id,ts,dur,cmd,client}
' > slowlog.csv
Nos pipelines de automação, recuperei os dados de todos os nós, normalizei os carimbos de data/hora (UTC) e criei métricas por comando, por cliente e por intervalo de tempo. Tenho o cuidado de exportar os dados antes de cada «SLOWLOG RESET» e de ajustar a frequência de rotação ao comprimento do registo, para que nenhum pico se perca.
Modelo de procedimento para a resposta a incidentes
Em casos agudos, começo por garantir o status quo: verifico o SLOWLOG LEN, exporto generosamente as últimas entradas e aumentei temporariamente o slowlog-max-len, para que nenhum dado seja eliminado pela rotação. Em seguida, reduzo moderadamente o Threshold, para poder detetar também padrões que se situem ligeiramente abaixo do limiar anterior. Paralelamente, controlo a CPU, a memória RSS, as falhas de página, o RTT da rede e os eventos de persistência (RDB/AOF). Se ocorrerem comandos isolados em grande quantidade, reduzo-os a curto prazo através de feature flags ou de limites de taxa mais restritos. No caso das teclas de atalho, distribuo os acessos (Key-Hashing/Shard-Spread) e, se necessário, aumentei a capacidade de replicação. Assim que o pico for ultrapassado, realizo uma análise mais aprofundada das causas e implemento correções permanentes no código e no modelo de dados.
Garantia de qualidade antes e depois das implementações
Antes dos lançamentos, reduzo significativamente o limiar do Slow Log no ambiente de staging, para detetar precocemente pontos de microineficiência. Defino limites de latência aceitáveis (por exemplo, p95/p99 por comando) e comparo-os com uma linha de base documentada. Após a implementação, acompanho de perto as entradas do Slow Log relativas aos serviços afetados; quaisquer desvios levam a uma reversão rápida ou a otimizações específicas. Uma implementação Canary por shard/zona ajuda-me a observar os efeitos de forma isolada. A comunicação é fundamental: cada cliente define um nome descritivo, para que eu possa atribuir imediatamente as entradas do Slow Log a um responsável – o que acelera enormemente a resolução do problema.
Lógica de decisão para o limiar e o comprimento do log
Não defino o limiar apenas de forma absoluta, mas sim de acordo com o contexto: Em nós muito rápidos com NVMe e CPU abundante, costumo reduzi-lo para 5–8 ms durante os períodos de produção, para detetar pontos de congestionamento subtis; no caso de hardware económico ou de tráfego em rajadas intenso, mantenho-me mais conservador, para que o registo continue a ter um sinal forte. Dimensiono o comprimento do registo de acordo com a taxa de comandos e o intervalo de exportação: quanto maior for a frequência de comandos, maior será a janela (por exemplo, 2048–4096), para que eu consiga capturar ciclos de tráfego completos. Nos testes de carga, defino deliberadamente um comprimento elevado e programo as exportações em tempo real, para não perder nenhum pico. Nos períodos de inatividade, reduzo esses valores para poupar memória e manter a análise focada.
Padrões frequentes na prática
Normalmente, distingo três categorias de causas: em primeiro lugar, operações O(N) dispendiosas em estruturas de grande dimensão (SORT, uniões de conjuntos/hash de grande dimensão, iterações completas); em segundo lugar, efeitos secundários do sistema (forks, desfragmentação, expulsões) e, em terceiro lugar, padrões de aplicação (acessos N+1, cálculos duplicados, falta de cache). As contramedidas decorrem diretamente daí: substituição de comandos e limitação da quantidade de dados, desacoplamento de operações pesadas em tarefas/filas, libertação assíncrona de objetos de grande dimensão, estratégias claras de TTL e invalidação, bem como maior agregação próxima do consumidor. Associo sempre estas medidas a métricas, para que os sucessos sejam mensuráveis e as regressões rapidamente visíveis.
Resumo compacto
Utilizo o Slow Log para registar a pura Hora do servidor Para tornar visíveis os comandos mais dispendiosos, defino limiares adequados e protejo os registos contra reinicializações. Através de configurações no ficheiro redis.conf ou com o comando CONFIG SET, mantenho o período de diagnóstico flexível, sem consumir memória desnecessária. A partir das entradas, deduzo padrões relativos a comandos, tempos e clientes e, em seguida, otimizo a seleção de comandos, o modelo de dados, o armazenamento em cache e o código da aplicação. Paralelamente, correlaciono as estatísticas do Slow Log com métricas do sistema e sinais de APM, para poder identificar claramente as causas. Desta forma, a Desempenho passam a ser previsíveis e os problemas de latência deixam de ser uma surpresa.
