Quando o Redis no Magento 2 cai ou responde lentamente, o impacto pode aparecer como páginas demoradas, erros intermitentes, sessões encerradas, painel instável ou aumento repentino no trabalho do PHP. Reiniciar o serviço pode aliviar o sintoma, mas também remove informações importantes e não corrige limites de memória, conexões incorretas ou concorrência entre aplicações.
Antes de limpar bancos do Redis ou alterar parâmetros em produção, registre o horário, as áreas afetadas e as mensagens apresentadas. Os nove testes abaixo ajudam a separar falhas de aplicação, rede, capacidade e configuração.
Como o Redis no Magento 2 afeta a loja?
O Magento pode utilizar Redis para diferentes finalidades, como cache padrão, cache de página e armazenamento de sessões. A distribuição exata depende do arquivo app/etc/env.php e da arquitetura da infraestrutura.
Uma indisponibilidade não produz necessariamente o mesmo efeito em todas as lojas. Se o Redis armazena sessões, clientes podem perder a autenticação ou encontrar comportamento inconsistente no carrinho. Quando ele atende caches, o PHP e o banco de dados podem receber mais solicitações. Já uma falha no cache de página pode aumentar o tempo de geração das respostas.
Se o problema estiver relacionado especificamente à entrega de páginas pelo proxy reverso, consulte também os testes para Varnish no Magento 2 que não retorna HIT. Redis e Varnish podem participar da mesma arquitetura, mas têm funções e diagnósticos diferentes.
1. Delimite o impacto antes de modificar o ambiente
Descubra primeiro se a falha afeta toda a loja ou apenas uma operação. Teste separadamente a página inicial, uma categoria, uma página de produto, o carrinho, o checkout e o Admin. Verifique também se usuários já autenticados apresentam comportamento diferente de visitantes anônimos.
Registre horário, URL, código HTTP, mensagem exibida e nó de aplicação que processou a requisição, quando houver mais de um. Um erro restrito a um servidor pode indicar configuração divergente ou falha de conectividade local, e não indisponibilidade geral do Redis.
2. Preserve e correlacione os registros
Consulte os logs do Magento, do PHP-FPM, do servidor web, do sistema operacional e do próprio Redis no intervalo da ocorrência. Pesquise mensagens relacionadas a conexão recusada, tempo limite, limite de clientes, memória insuficiente e perda de conexão.
grep -RiE "redis|connection refused|timed out|read error" var/log/Evite apagar logs ou reiniciar todos os componentes antes dessa coleta. Caso a falha também produza respostas HTTP 500, o roteiro de diagnóstico do erro 500 no Magento 2 ajuda a verificar PHP, servidor web e aplicação sem destruir evidências.
3. Teste a conexão a partir do servidor da aplicação
O teste precisa partir do mesmo ambiente que executa o Magento. Uma resposta obtida diretamente no servidor do Redis não comprova que os nós do PHP conseguem alcançá-lo.
redis-cli -h ENDERECO_DO_REDIS -p PORTA PINGUma resposta PONG confirma apenas a comunicação básica naquele momento. Ela não descarta latência, saturação, falha intermitente ou autenticação divergente. Se o ambiente utiliza TLS, socket Unix, autenticação ou serviço gerenciado, use o cliente e os parâmetros correspondentes à arquitetura.
Não coloque senhas diretamente em comandos que possam ficar no histórico do terminal ou ser vistas na lista de processos. Faça o teste com uma conta autorizada e preserve os controles de acesso existentes.
4. Revise a configuração do app/etc/env.php
Inspecione o arquivo sem publicá-lo em tickets, chats ou repositórios. Endereços, portas, credenciais, números de banco, prefixos e opções de persistência podem ser informações sensíveis.
Confira se todos os nós de aplicação usam a mesma configuração esperada e se cache, cache de página e sessões apontam para os destinos planejados. Bancos ou prefixos compartilhados indevidamente entre produção, homologação e outras lojas podem causar colisões, invalidações inesperadas e consumo de memória difícil de explicar.
Também verifique alterações recentes em variáveis de ambiente, secrets, DNS, balanceadores e regras de firewall. Uma implantação pode manter o código correto e, ainda assim, entregar parâmetros diferentes para apenas parte dos servidores.
5. Meça o consumo de memória do Redis
Use informações do próprio serviço para comparar memória utilizada, limite configurado, fragmentação e pico de consumo:
redis-cli -h ENDERECO_DO_REDIS -p PORTA INFO memoryObserve campos como used_memory, used_memory_peak, maxmemory e mem_fragmentation_ratio. Um valor isolado não determina a causa; compare o resultado com o histórico, a capacidade disponível e o horário do incidente.
Não aumente maxmemory automaticamente. O servidor precisa manter memória para o sistema operacional e para outros processos. Da mesma forma, trocar a política de remoção sem entender quais dados estão armazenados pode transformar lentidão em perda de sessões ou descarte excessivo de chaves.
6. Verifique expulsões, falhas e comandos lentos
Os contadores de estatísticas ajudam a descobrir se o Redis está removendo dados, recusando conexões ou registrando quantidade anormal de falhas:
redis-cli -h ENDERECO_DO_REDIS -p PORTA INFO stats
redis-cli -h ENDERECO_DO_REDIS -p PORTA SLOWLOG GET 20Analise especialmente a evolução de chaves expulsas, conexões rejeitadas, acertos e falhas de cache. No slow log, procure comandos incompatíveis com o padrão normal da operação ou executados por integrações e ferramentas administrativas.
Evite executar KEYS * em uma base movimentada. Para investigações controladas, prefira mecanismos iterativos, filtros por prefixo e ferramentas de observabilidade que não bloqueiem o serviço.
7. Confira clientes conectados e tempos limite
O Redis pode estar saudável, mas próximo do limite de clientes ou recebendo conexões demais por falta de reaproveitamento adequado. Consulte os indicadores de clientes e, se permitido pela política operacional, a lista de conexões:
redis-cli -h ENDERECO_DO_REDIS -p PORTA INFO clients
redis-cli -h ENDERECO_DO_REDIS -p PORTA CLIENT LISTCompare a quantidade de clientes com o volume habitual e procure conexões muito antigas, ociosas ou concentradas em um único host. Reiniciar o Redis elimina temporariamente essas conexões, mas elas voltarão se a origem estiver no PHP-FPM, em consumidores, extensões ou processos externos.
8. Descubra se cargas diferentes estão concorrendo
Cache, sessões e cache de página possuem padrões distintos de leitura, gravação e expiração. Quando todas as cargas compartilham a mesma instância sem planejamento, uma campanha, importação ou invalidação de cache pode afetar partes inesperadas da loja.
Mapeie quais aplicações usam o serviço e quais bancos ou prefixos pertencem a cada uma. Verifique ainda consumidores, rotinas de integração e tarefas agendadas. Se os picos coincidem com processos periódicos, investigue o agendamento antes de redimensionar a infraestrutura. O guia sobre cron do Magento 2 pode ajudar a localizar tarefas acumuladas ou executadas fora do comportamento esperado.
9. Valide a correção com um teste controlado
Depois de identificar a causa provável, altere um componente por vez e registre o estado anterior. Valide navegação anônima, login, carrinho, checkout, Admin, cache e tarefas assíncronas. Em ambientes com vários nós, confirme que todos receberam a mesma configuração.
Acompanhe memória, latência, conexões, expulsões e erros durante um período representativo. Uma resposta rápida logo após limpar o cache não comprova estabilidade, pois a carga e a quantidade de chaves ainda podem estar abaixo do normal.
O que evitar durante o diagnóstico
- executar
FLUSHALLouFLUSHDBsem identificar o conteúdo e o impacto do banco; - reiniciar Redis, PHP-FPM e servidor web simultaneamente;
- compartilhar o conteúdo completo do
env.phpsem remover segredos; - aumentar memória e limites de clientes sem investigar a tendência de consumo;
- alterar timeout para apenas esconder conexões lentas;
- testar somente a página inicial e considerar o checkout validado.
Conclusão
Problemas no Redis no Magento 2 exigem mais do que um reinício. Conectividade, memória, clientes, latência, separação de cargas e consistência entre servidores precisam ser analisadas em conjunto. Preservar evidências e medir o comportamento antes e depois da correção reduz o risco de uma nova queda durante o tráfego real.
Se a loja apresenta erros recorrentes, perda de sessões ou lentidão associada ao Redis, uma revisão técnica da configuração e da infraestrutura pode localizar o gargalo sem recorrer a limpezas indiscriminadas. A equipe do SuporteMagento.com.br pode auxiliar no diagnóstico e na validação da operação.
Perguntas frequentes sobre Redis no Magento 2
Reiniciar o Redis resolve a lentidão do Magento 2?
O reinício pode aliviar temporariamente conexões presas ou pressão de memória, mas não corrige a origem. Antes de reiniciar, preserve logs e indicadores de memória, clientes, erros e expulsões.
Posso executar FLUSHALL para limpar o cache?
Não sem conhecer todo o conteúdo da instância. O comando remove dados de todos os bancos e pode atingir sessões, outras lojas ou aplicações. Use os mecanismos de limpeza do Magento quando o objetivo for invalidar caches da plataforma.
Como saber se o Magento está conectado ao Redis?
Revise o app/etc/env.php, teste a conectividade a partir dos servidores da aplicação e correlacione os clientes conectados com requisições controladas. O comando PING sozinho não comprova que o Magento usa a configuração correta.
Redis e Varnish fazem a mesma coisa no Magento?
Não. O Redis pode armazenar caches, sessões e outros dados temporários, enquanto o Varnish atua como proxy reverso para entregar respostas HTTP armazenadas. Uma loja pode utilizar ambos.
