Nivel 3 · 25 min

Troubleshooting de Redis

El troubleshooting de Redis requiere saber qué métricas mirar, cómo interpretar los comandos de diagnóstico y cómo resolver los problemas más comunes: alta tasa de miss, latencia elevada, presión de memoria y problemas de persistencia.

Evicción y gestión de memoria

INFO memory muestra used_memory, used_memory_rss, mem_fragmentation_ratio. Si mem_fragmentation_ratio '>' 1.5, hay fragmentación de memoria — Redis usa más RAM del OS de la que consume lógicamente. Solución: MEMORY PURGE (Redis 4+) o reiniciar. Para diagnosticar qué ocupa más memoria: MEMORY DOCTOR, OBJECT ENCODING key. Cuando Redis alcanza maxmemory con noeviction, los writes empiezan a fallar — configurar la política correcta y alertas antes de llegar al límite.

Diagnóstico de alta tasa de miss

INFO stats muestra keyspace_hits y keyspace_misses. Hit rate = hits / (hits + misses). Un hit rate bajo ('<' 80%) indica problemas: TTL demasiado corto, caché de capacidad insuficiente (maxmemory demasiado chico), errores en la construcción de claves (prefijos incorrectos, serialización diferente), o datos que simplemente no se cachean correctamente. MONITOR permite ver comandos en tiempo real (úsalo con cuidado en producción — impacta performance).

Latencia en Redis y persistencia

Redis tiene latencia de sub-milisegundo normalmente. Si ves latencia alta: SLOWLOG GET muestra los comandos más lentos (configurable con slowlog-log-slower-than). Las causas comunes: comandos O(N) sobre colecciones grandes (KEYS *, SMEMBERS en set enorme, LRANGE sin límite), BGSAVE/BGREWRITEAOF (fork del proceso que pausa Redis brevemente con CoW), fragmentación de memoria, problemas de red. Persistencia: RDB hace snapshots periódicos (riesgo de pérdida de datos hasta el último snapshot), AOF persiste cada write (mejor durabilidad, restart más lento). Tradeoffs según el nivel de durabilidad requerido.

Puntos clave

INFO stats + keyspace_hits/misses = diagnóstico de hit rate. INFO memory = diagnóstico de uso de RAM y fragmentación.
SLOWLOG GET identifica comandos lentos. Las causas más comunes: KEYS *, SMEMBERS en sets grandes, BGSAVE durante alta carga.
RDB: recovery rápido, pérdida de datos hasta último snapshot. AOF: mejor durabilidad, recovery más lento. Usá ambos en producción crítica.

Code example

-- Diagnosticar el estado de Redis
INFO all                    -- todo el estado
INFO memory                 -- uso de memoria
INFO stats                  -- hits/misses
SLOWLOG GET 25             -- ultimos 25 comandos lentos
SLOWLOG RESET              -- limpiar slowlog
MEMORY DOCTOR              -- sugerencias de memoria
OBJECT ENCODING mi:clave   -- como esta almacenado
LATENCY HISTORY event      -- historial de latencia