Redis as object cache. Not a second database, and not open on the internet.
WordPress object cache, a full memory limit, a socket the plugin cannot see. We bind it to localhost. Port 6379 does not belong on a public firewall.
Memory, the socket, a cache that is lying
Redis grew until the VPS swapped. We set a limit and an eviction policy that fits a cache. A cache may drop keys. That is the point. It is not where the orders live.
Unix socket versus 127.0.0.1, a password the plugin does not have, or SELinux on AlmaLinux denying the path. The site still works. It is just not cached.
Object cache holding an old option. We flush the cache. We do not flush the database. A full-page cache in NGINX is a separate layer.
Sessions and carts do not belong only in Redis
If the application stores the only copy of a session there, a restart logs everyone out. We say that before enabling persistence or turning it off. Redis is not a substitute for MariaDB, and it is not a fix for a slow query.
€55 an hour to install, bind, or stop it filling the RAM
Minimum 1 hour. A public Redis with no password is closed in the same hour. That is a security fault, not a tuning request.
Redis eating the RAM, or the object cache not connecting?
Tell us if it is WordPress and whether port 6379 is public. No root password in the first message.
