En entornos donde un mismo servidor aloja varios WordPress bajo RunCloud, la eficiencia del object cache se convierte en un factor clave para el rendimiento. Redis, cuando se configura adecuadamente, puede reducir drásticamente la carga de MariaDB y acelerar la entrega de contenido dinámico.
Sin embargo, en instalaciones por defecto suelen faltar ajustes finos de memoria, seguridad y monitorización. Este artículo explica cómo optimizar Redis en un servidor con RunCloud + Ubuntu + LiteSpeed + MariaDB + Redis, preparado para manejar hasta una docena de sitios WordPress de forma segura y estable.
1. Redis como caché de objetos (sin persistencia)
Cuando Redis solo se usa como object cache de WordPress, no es necesario almacenar datos en disco: si se reinicia el servicio, el propio plugin de caché reconstruirá la información automáticamente.
En /etc/redis/redis.conf ajusta:
save ""
appendonly no
Lenguaje del código: JavaScript (javascript)Esto evita generar ficheros RDB y AOF, reduciendo uso de disco y pausas innecesarias.
2. Definir límite de memoria y política de expulsión
Un error común es no fijar límites de memoria, lo que puede saturar el servidor. En un VPS con 12 GB de RAM, asignar unos 2,5 GB para Redis es un buen punto de partida:
maxmemory 2560mb
maxmemory-policy allkeys-lru
maxmemory-samples 10
allkeys-lru→ Redis eliminará las claves menos utilizadas.maxmemory-samples 10→ mejora la precisión del algoritmo de expulsión.
3. Minimizar pausas y latencia
Cuando Redis elimina miles de claves de golpe, puede bloquear momentáneamente el servidor. Para evitarlo:
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
Así las operaciones de borrado se procesan en segundo plano.
4. Expiración más eficiente
Para sitios con tráfico elevado conviene ajustar cómo Redis limpia objetos caducados:
hz 20
dynamic-hz yes
active-expire-effort 5
Esto acelera la liberación de memoria sin penalizar demasiado a la CPU.
5. Seguridad con contraseña (requirepass)
Aunque Redis esté limitado a 127.0.0.1, nunca debe usarse sin autenticación. Añade en redis.conf:
requirepass TU_PASSWORD_MUY_LARGO
La contraseña debe ser única, robusta y diferente a la de MySQL o WordPress.
6. Conexión segura con redis-cli
Si requirepass está activo, Redis requiere autenticación. Dos métodos:
🔹 Conexión directa:
redis-cli -h 127.0.0.1 -p 6379 -a 'TU_PASSWORD_MUY_LARGO' ping
Lenguaje del código: JavaScript (javascript)🔹 Autenticación tras conexión:
redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> AUTH TU_PASSWORD_MUY_LARGO
OK
127.0.0.1:6379> ping
PONG
Lenguaje del código: CSS (css)7. Integración con WordPress en RunCloud
En cada wp-config.php define los parámetros de Redis:
define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'TU_PASSWORD_MUY_LARGO');
define('WP_REDIS_PREFIX', 'sitio1_'); // Cambia el prefijo para cada WordPress
Lenguaje del código: JavaScript (javascript)Si usas LiteSpeed Cache:
- Activa Object Cache → Redis.
- Configura host
127.0.0.1, puerto6379y la contraseña. - Define un prefijo único por cada WordPress para evitar colisiones.
8. Monitorización con redis-cli
Algunos comandos útiles para verificar el estado de Redis:
- Memoria usada:
redis-cli -a 'TU_PASSWORD' INFO memory | egrep 'used_memory_human|maxmemory' - Evicciones de claves:
redis-cli -a 'TU_PASSWORD' INFO stats | grep evicted_keys - Clientes conectados:
redis-cli -a 'TU_PASSWORD' INFO clients | grep connected_clients
Si el número de evicted_keys crece demasiado rápido, considera aumentar maxmemory o revisar TTL de los objetos cacheados.
9. Ajustes adicionales de sistema
Optimizar también el kernel y la configuración del sistema ayuda a Redis a rendir mejor:
En /etc/sysctl.d/60-redis-tuning.conf:
net.core.somaxconn = 1024
vm.overcommit_memory = 1
Y desactiva Transparent Huge Pages (THP):
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
Lenguaje del código: PHP (php)Conclusión
Con estos ajustes, Redis queda preparado para entornos de RunCloud con múltiples WordPress:
✅ Seguridad reforzada con requirepass.
✅ Límite de memoria controlado (2,5 GB).
✅ Evicción inteligente con LRU.
✅ Eliminación en background para evitar micro-paradas.
✅ Monitorización sencilla vía redis-cli.
El resultado: menos consultas a MariaDB, mejor tiempo de respuesta y mayor estabilidad, incluso con 12 WordPress en paralelo.
Preguntas frecuentes (FAQ)
¿Cuánto RAM debo asignar a Redis en un servidor con varios WordPress?
Depende de los plugins y tráfico, pero como regla general puedes reservar entre un 15 % y 25 % de la RAM total. En un servidor de 12 GB, unos 2–3 GB son adecuados.
¿Es seguro usar Redis sin contraseña si solo escucha en 127.0.0.1?
No es recomendable. Aunque solo acepte conexiones locales, siempre existe el riesgo de accesos indebidos. Usa requirepass.
¿Cómo evitar que varios WordPress usen la misma caché en Redis?
Configura un prefijo distinto (WP_REDIS_PREFIX) para cada instalación de WordPress. Así se separan las claves en memoria.
¿LiteSpeed Cache y Redis hacen lo mismo?
No. LiteSpeed Cache almacena páginas HTML completas, mientras que Redis acelera la caché de objetos internos de WordPress. Juntos ofrecen el mejor rendimiento.
