Mi servidor Redis se come toda la RAM cuando uso Lua scripts con KEYS * ¿Es un bug o lo estoy haciendo mal?

Improv

Llevo días peleándome con un problema que me tiene loco. Tengo un Redis Cluster en producción (v7.2) donde ejecuto scripts Lua para procesar lotes de datos. El problema aparece cuando en el script uso redis.call('KEYS', pattern) aunque sea con un patrón específico (ej: user:session:*).

Al ejecutarlo, Redis consume toda la RAM disponible (64GB) en segundos y se cae. Los logs muestran: OOM command not allowed when used memory > 'maxmemory'.

Lo extraño es que si ejecuto KEYS desde redis-cli directamente, funciona (aunque es lento). Solo falla dentro del script Lua. ¿Alguien ha enfrentado esto? Mi script simplificado:

local pattern = ARGV[1]
local keys = redis.call('KEYS', pattern)
for i, key in ipairs(keys) do
    redis.call('DEL', key)
end
return #keys

¿Es un bug de Redis o hay algo fundamental que estoy ignorando sobre KEYS en Lua?

Classical

KEYS es el comando prohibido por excelencia en producción, especialmente en Lua. No es un bug, es el comportamiento esperado. Cuando llamas a KEYS desde Lua, Redis bloquea el dataset completo mientras construye el array de resultados en memoria. Si tienes millones de keys, eso explota.

En redis-cli puede 'funcionar' porque no estás dentro de una transacción atómica de Lua. La solución: usa SCAN en lugar de KEYS, incluso dentro de scripts. Así:

local cursor = '0'
local keys = {}
repeat
    local result = redis.call('SCAN', cursor, 'MATCH', ARGV[1])
    cursor = result[1]
    for _, key in ipairs(result[2]) do
        table.insert(keys, key)
    end
until cursor == '0'

Pero ojo: SCAN dentro de Lua pierde la garantía de atomicidad total. Es un trade-off.

Tea

Discrepo un poco con el comentario anterior. SCAN en Lua es peligroso porque puede no ver keys que se modifican durante la ejecución. El problema real aquí es el diseño: ¿por qué necesitas borrar miles de keys en un script atómico?

Me suena a que estás usando Redis como base de datos primaria para sesiones, y eso es antipatrón. Usa TTL automático o un job externo (con un worker en Python/Go) que haga SCAN incrementalmente fuera de Redis.

Si insistes en Lua, prueba con redis.replicate_commands() al inicio del script. Eso cambia cómo Redis maneja la replicación del script y puede afectar el uso de memoria (aunque no lo soluciona mágicamente).

Improv

Gracias por los aportes. Entiendo lo de KEYS vs SCAN, pero lo que me desconcierta es la diferencia de comportamiento entre CLI y Lua. Probé el script con SCAN y mejora, pero como dicen, pierdo atomicidad.

El contexto: son sesiones caducadas que por un bug no tuvieron TTL. Necesito borrarlas en un mantenimiento puntual, no es la operación normal. ¿Hay forma de que un script Lua con SCAN sea 'suficientemente atómico' si desactivo writes durante la ventana de mantenimiento?

Probé redis.replicate_commands() y el consumo de RAM bajó un 70%, pero sigue siendo alto. Parece que el garbage collector de Lua dentro de Redis no libera rápido.

PetOwner

Si es un mantenimiento puntual, olvídate de Lua. Usa redis-cli --scan --pattern 'user:session:*' | xargs -L 1000 redis-cli del desde una máquina externa. Es más seguro.

Pero si quieres la respuesta técnica pura: el problema de memoria en Lua ocurre porque KEYS devuelve una tabla Lua con todas las keys referenciadas. Hasta que el script termina, esas referencias no se liberan. Redis prioriza no bloquear el servidor, así que asigna memoria sin límite para el script. En CLI, el cliente recibe el stream de respuestas y las va liberando.

Un hack feo pero funcional: divide el KEYS en chunks dentro del script con múltiples llamadas y collectgarbage() entre ellas (sí, Lua en Redis lo soporta).

Drones

Esto huele a que estás en Redis Cluster. ¿Has probado ejecutar el script en cada nodo por separado? KEYS solo opera en el keyspace del nodo actual. Si tu patrón abarca múltiples slots, necesitas un script por nodo.

Te comparto mi solución para purgas masivas en Cluster:

for node in $(redis-cli cluster nodes | grep master | awk '{print ?}' | cut -d '@' -f1); do
    redis-cli -h ${node%:*} -p ${node#*:} --eval purge_script.lua , 'user:session:*'
done

El script usa SCAN con COUNT 100 y un límite de iteraciones. Nunca falla por OOM.

Improv

¡El dato del Cluster es clave! Efectivamente, estamos en Cluster y no había considerado que KEYS en Lua se ejecuta solo en el nodo que recibe el comando. Eso explica por qué veía un consumo desproporcionado en un solo nodo.

Combinando sus sugerencias: voy a implementar un script por nodo con SCAN + COUNT bajo, y añadiré collectgarbage() cada 1000 keys. Haré la purga en horario de menor tráfico.

Resumen de aprendizaje: KEYS en Lua es una bomba en Cluster, SCAN rompe atomicidad pero es necesario, y siempre verificar en qué nodo se ejecuta. Gracias a todos.

Blockchain

Tu enfoque con SCAN y collectgarbage() es sólido, pero cuidado con la atomicidad: si usas SCAN en un script Lua, pierdes la garantía atómica de Redis, lo que podría causar inconsistencias si hay escrituras concurrentes durante la purga. En lugar de collectgarbage() cada 1000 keys, considera ajustar COUNT dinámicamente basado en la memoria disponible del nodo; puedes usar redis.call('INFO', 'memory') para monitorear y pausar si se acerca al límite. Para Cluster, también evalúa usar EVALSHA con scripts pre-cargados en cada nodo para reducir overhead de red. ¿Has probado con Redis 7 y las mejoras en gestión de memoria para Lua? En versiones recientes, el consumo puede ser más controlado si configuras lua-memory-limit.