search

valkey-io / valkey

A flexible distributed key-value datastore that supports both caching and beyond caching workloads.
https://valkey.io
Other
15.51k stars 571 forks source link

Add maxmemory-reserved-scale parameter to evict keys earlier #742

Open hwware opened 2 months ago

hwware commented 2 months ago

Recap https://github.com/redis/redis/pull/11749

User need to enable lazyfree-lazy feature, thus OOM will never happen or delay sometime.

Azure already implements this feature https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-memory-management

hpatro commented 2 months ago

Could you add some more details to the issue here? I couldn't find details about maxmemory-reserved-scale in the azure link.

hwware commented 1 month ago

Generally, when clients set maxmemory-policy as allkeys-lru or other memory eviction policies, and maxmemory as well, If server runs as write-heavy workloads, the data stored in memory could reach the maxmemory limit very quickly, then OOM message will be reported.

If we have maxmemory-reserved-scale parameter and client enable the lazyfree-lazy feature, for example, we can set maxmemory-reserved-scale as 0.8, it means key eviction begin when used memory reaches 8GB if maxmemory is 10GB, thus, server could continue process clients data and OOM will not happen at this time.

Thus, we can see the benefit is we can delay OOM time, but we need pay for less memory available.