¿Por qué Redis usa mucha CPU? Técnicas de depuración y optimización

Un alto uso de CPU en Redis generalmente significa una de tres cosas: Redis está haciendo demasiado trabajo de comandos en su ruta de ejecución principal, el trabajo en segundo plano, como la persistencia, está agregando presión, o los clientes están enviando tráfico de una forma que Redis no puede procesar de manera eficiente. La solución depende de cuál de estas sea cierta.

No empieces reiniciando Redis a menos que el servicio ya esté fallando. Un reinicio puede eliminar el síntoma y borrar la evidencia. Comienza capturando la latencia de comandos, la mezcla de comandos, el número de clientes, el estado de persistencia y la CPU del host. Esos datos te indican si tienes un comando malo, un patrón de tráfico malo, un núcleo sobrecargado o un host ruidoso.

Entendiendo la arquitectura de Redis y la carga de CPU

A menudo se describe a Redis como de un solo hilo, lo cual es mayormente cierto para la ejecución de comandos, pero Redis moderno también puede usar hilos en segundo plano y E/S opcional por hilos. El punto práctico sigue siendo el mismo: un comando que tarda demasiado puede retrasar a otros clientes, y un núcleo saturado puede ser suficiente para crear latencia visible incluso cuando la máquina tiene CPU inactiva en otro lugar.

Factores clave que influyen en la carga de CPU de Redis

Las causas comunes son comandos costosos, valores grandes, scripts Lua, demasiados comandos pequeños enviados uno por uno, alta rotación de conexiones, actividad de persistencia y presión de memoria que obliga al kernel a trabajar más de lo que Redis espera.

Depurando el alto uso de CPU

Antes de optimizar, debes identificar con precisión la fuente de la carga. Las herramientas de monitoreo y los comandos integrados de Redis son esenciales para el diagnóstico.

1. Usando los comandos INFO y LATENCY

El comando INFO proporciona una instantánea del estado del servidor. Concéntrate en la sección de CPU y las estadísticas de comandos.

redis-cli INFO cpu

Observa la tasa de cambio, no solo los valores absolutos. used_cpu_user aumentando rápidamente a menudo apunta a procesamiento de comandos. used_cpu_sys aumentando rápidamente puede apuntar a trabajo del kernel como redes, gestión de memoria o actividad relacionada con disco.

Las herramientas de latencia muestran las clases de eventos que Redis ha observado:

redis-cli LATENCY LATEST
redis-cli LATENCY DOCTOR

2. Identificando comandos lentos con SLOWLOG

El Slow Log de Redis registra comandos que exceden un tiempo de ejecución especificado. Esta es tu herramienta más directa para encontrar operaciones con bajo rendimiento.

El slow log de Redis registra comandos cuyo tiempo de ejecución supera un umbral. No incluye el tiempo de red ni el tiempo de espera en el pool de clientes, por lo que es mejor usarlo junto con métricas de latencia de la aplicación.

Configuración de ejemplo:

slowlog-log-slower-than 1000
slowlog-max-len 1024

Recuperando el registro:

redis-cli SLOWLOG GET 10

Revisa el nombre del comando, los nombres de las claves y la duración. Si KEYS, HGETALL grande, SMEMBERS enorme, rangos amplios de conjuntos ordenados o scripts Lua dominan el registro, el problema de CPU probablemente sea impulsado por la aplicación.

3. Monitoreando la actividad de red y clientes

MONITOR es tentador durante un incidente, pero es costoso en un servidor ocupado. Prefiere INFO commandstats, INFO clients, slow log, métricas de la biblioteca del cliente y muestreo desde una réplica si tienes una.

Comandos útiles:

redis-cli INFO commandstats
redis-cli INFO clients
redis-cli CLIENT LIST

Si el volumen de comandos se duplicó después de un despliegue, puedes verlo en cmdstat_get, cmdstat_hgetall o contadores similares. Si los clientes se conectan y desconectan constantemente, arregla el pooling antes de ajustar Redis.

Causas comunes y estrategias de optimización

Una vez que hayas identificado los comandos o procesos problemáticos, aplica técnicas de optimización específicas.

1. Eliminando comandos bloqueantes

Las victorias más rápidas generalmente provienen de eliminar comandos que obligan a Redis a recorrer un gran espacio de claves o serializar un valor enorme.

Comando ineficiente	Por qué causa alta CPU	Optimización / Alternativa
KEYS *	Escanea todo el espacio de claves. O(N).	Usa SCAN iterativamente o reestructura el acceso a datos.
FLUSHALL / FLUSHDB	Elimina cada clave a menos que se use modo asíncrono.	Usa eliminación cuidadosa con alcance, UNLINK, o vaciado asíncrono solo cuando sea apropiado.
HGETALL, SMEMBERS (en conjuntos muy grandes)	Recupera toda la estructura en memoria y la serializa.	Usa HSCAN, SSCAN, o divide estructuras grandes en claves más pequeñas.

Usa UNLINK en lugar de DEL para claves muy grandes. DEL libera memoria de forma síncrona. UNLINK elimina la clave del espacio de claves y libera memoria de forma asíncrona, lo que generalmente reduce la latencia visible durante eliminaciones grandes.

# En lugar de DEL large_key
UNLINK large_key

2. Optimizando la persistencia (RDB y AOF)

Las instantáneas RDB y las reescrituras AOF usan procesos hijos en segundo plano y aún pueden afectar al padre a través del costo de fork, copia en escritura de memoria, ancho de banda de disco y contención de CPU.

• Instantáneas RDB: Si guardas con frecuencia (por ejemplo, cada minuto), las llamadas repetidas a fork() causarán picos recurrentes de CPU. Reduce la frecuencia de los guardados automáticos.
• Reescritura AOF: La reescritura AOF (BGREWRITEAOF) también consume muchos recursos. Redis intenta optimizar esto realizando E/S mínima, pero el uso de CPU aumentará durante el proceso.

Si la persistencia coincide con los picos de CPU, verifica INFO persistence y las métricas de disco del host. Puedes reducir la frecuencia de RDB, programar copias de seguridad pesadas lejos de los picos de tráfico, dejar más espacio libre de memoria o mejorar el almacenamiento. Pausar la persistencia puede reducir la carga, pero también aumenta el riesgo de pérdida de datos, por lo que debe ser una decisión operativa deliberada.

3. Manejando la fragmentación de memoria y el swapping

Si bien los problemas de memoria a menudo se asocian con un alto uso de memoria, la fragmentación severa de memoria o, peor aún, que el sistema operativo comience a intercambiar datos de Redis a disco (thrashing) aumentará drásticamente el uso de CPU mientras el kernel lucha por gestionar la memoria.

• Verifica el swapping: Usa herramientas del sistema operativo (vmstat, top) para verificar si el sistema está intercambiando activamente páginas de memoria pertenecientes al proceso de Redis.
• Ratio de fragmentación de memoria: Verifica mem_fragmentation_ratio en INFO memory. Un ratio alto es una pista de que el comportamiento del asignador puede estar desperdiciando memoria, pero confírmalo con RSS, tamaño del conjunto de datos y métricas de memoria del host.

Si ocurre swapping, reduce el conjunto de datos, baja maxmemory, mueve trabajo fuera del host o agrega memoria. Redis no está diseñado para rendir bien cuando su conjunto de datos activo se está paginando a disco.

4. Optimización de red y pipelining

Si la carga de CPU sigue a un alto número de comandos pequeños, el problema puede ser la sobrecarga de comandos y la rotación de red, más que un comando obviamente lento.

El pipelining permite a un cliente enviar múltiples comandos sin esperar una respuesta después de cada uno. Reduce los viajes de ida y vuelta y puede mejorar el rendimiento para escrituras o lecturas por lotes. Mantén los lotes de pipeline acotados; un pipeline con miles de comandos pesados puede crear su propio pico de latencia.

Mejores prácticas para un rendimiento sostenido

Para prevenir futuros picos de CPU, adopta estas mejores prácticas arquitectónicas y de configuración:

1. Usa UNLINK para claves que puedan ser grandes.
2. Reemplaza KEYS con SCAN, y reemplaza las lecturas completas de colecciones con lecturas basadas en cursor.
3. Rastrea INFO commandstats después de los despliegues para que un nuevo patrón de comandos no te sorprenda.
4. Ajusta la persistencia teniendo en cuenta el espacio real de disco y memoria.
5. Si una instancia de Redis está legítimamente saturada después de arreglar comandos, divide la carga de trabajo con Redis Cluster, sharding del lado del cliente, instancias separadas de caché/sesión, o una instancia más grande con mejor rendimiento de un solo núcleo.

Una lista de verificación rápida para incidentes

Durante un pico, ejecuta:

redis-cli INFO cpu
redis-cli INFO commandstats
redis-cli INFO clients
redis-cli INFO memory
redis-cli INFO persistence
redis-cli SLOWLOG GET 20
redis-cli LATENCY LATEST

Luego alinea esos resultados con los despliegues de la aplicación, trabajos cron, cambios de tráfico, eventos de persistencia y métricas del host. Un alto uso de CPU en Redis generalmente se puede solucionar, pero la solución es específica: elimina el comando costoso, agrupa al cliente charlatán, detén la rotación de conexiones, da espacio a la persistencia para trabajar, o divide la carga de trabajo cuando una sola instancia está genuinamente en su límite.