Cap the cache. A bigger maxmemory is not the optimization.
WordPress object cache that grew until the VPS swapped. Eviction on, persistence off unless the app stores the only copy of a session there.
Limit, policy, and what is allowed to disappear
A fraction of RAM, not all of it. MariaDB and PHP still have to run. allkeys-lru is right for a cache. It is wrong if someone stored a queue in the same instance.
RDB snapshots on a pure cache wake the disk for nothing. We turn them off after confirming a restart may empty the cache. Sessions that live only in Redis are called out first.
A low hit rate means the plugin is writing keys nobody reads. We say so. Adding RAM does not fix a cache of unique keys.
Port 6379 open to the world is a security job
Optimization assumes Redis is already bound to localhost and the plugin can connect. A public port is closed before any tuning. A slow query is still MariaDB.
€55 an hour. The first look is info memory.
Minimum 1 hour. If the used memory is under the cap and the hit rate is fine, we stop. There is nothing to optimize.
Redis the largest process on a small VPS?
Tell us the RAM and whether it is a WordPress object cache. No root password in the first message.