-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bitnami/valkey-cluster] Valkey Eviction Policy #31471
Comments
Hi! Thank you so much for reporting! Would this value help?
Something like this:
|
@javsalgar yes this would help a lot to configure like you said: valkey: |
Hi, Did you try it? Did you find any issue? The value already existis in the chart. |
I didn't see the value in the documentation https://artifacthub.io/packages/helm/bitnami/valkey-cluster Is it on the correct level?
|
It would be like
|
@javsalgar thank you very much, I tried as you mentioned:
But I get: valkey-valkey-cluster *** FATAL CONFIG FILE ERROR (Version 8.0.2) *** valkey-valkey-cluster Reading the configuration file, at line 2261 valkey-valkey-cluster >>> 'maxmemory-policy: allkeys-lru' |
Could you try removing the :? I think it is without colons |
Thank you very much @javsalgar, this worked |
Name and Version
bitnami/valkey-cluster 2.1.1
What is the problem this feature will solve?
My Valkey-cluster helm chart crashes because of memory pressure and there isn't any eviciton policy,
What is the feature you are proposing to solve the problem?
The Valkey clusterhelm chart https://artifacthub.io/packages/helm/bitnami/valkey-cluster should support also the eviction of old keys like in https://valkey.io/topics/lru-cache/ described. Within this general valkey setup we can configure that old keys expire, see:
Eviction policies
The exact behavior Valkey follows when the maxmemory limit is reached is configured using the maxmemory-policy configuration directive.
The following policies are available:
noeviction: New values aren't saved when memory limit is reached. When a database uses replication, this applies to the primary database
allkeys-lru: Keeps most recently used keys; removes least recently used (LRU) keys
allkeys-lfu: Keeps frequently used keys; removes least frequently used (LFU) keys
volatile-lru: Removes least recently used keys with a time-to-live (TTL) set.
volatile-lfu: Removes least frequently used keys with a TTL set.
allkeys-random: Randomly removes keys to make space for the new data added.
volatile-random: Randomly removes keys with a TTL set.
volatile-ttl: Removes keys with a TTL set, the keys with the shortest remaining time-to-live value first.
What alternatives have you considered?
No response
The text was updated successfully, but these errors were encountered: