Replies: 4 comments 11 replies
-
|
WIP |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
There is ongoing work to bring Active expiration and enable free list revivification in the Read-Modify-Write route of changes. I am actively working on implementing both. You can track the PRs in the comments I have above. |
Beta Was this translation helpful? Give feedback.
-
@hamdaankhalid To enable active expiration and free list revivification, which settings need to be configured in the Garnet.conf file? |
Beta Was this translation helpful? Give feedback.
-
@hamdaankhalid To enable active expiration and free list revivification, which settings need to be configured in the Garnet.conf file? |
Beta Was this translation helpful? Give feedback.
-
|
Active expiration is still WIP. New revivification path has been merged in latest Garnet, so make sure you are on the latest version and you can leave config as is for revivification. Active expiration however will take a bit to be merged, I am estimating to merge it sometime next week. |
Beta Was this translation helpful? Give feedback.
-
|
Based on your usage patterns I do believe you will have to wait for Active Expiration to see the new Revivification paths kick in. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, Hadaankhalid, I have updated the Garnet package to the latest version (Garnet v1.0.65). Okay, we will wait for the Active Expiration release. |
Beta Was this translation helpful? Give feedback.
-
|
Moreover, I've observed that the Garnet Server consistently utilizes a high percentage of available memory, typically around 97–98%, which is causing performance issues. Please refer to the screenshot below for reference.
|
Beta Was this translation helpful? Give feedback.
-
|
What are the exact server configuration settings (garnet.conf and/or command line)? |
Beta Was this translation helpful? Give feedback.
-
@badrishc, my Garnet.conf settings are listed below. Please review and let me know if any changes are needed. |
Beta Was this translation helpful? Give feedback.
-
|
"MemorySize" : "4g", => why such a large memory configuration? please set this based on how much memory you want to use for the string (main) store. "IndexSize" : "128m", => can set this to smaller based on how many objects you expect to cache. see the logger trace output of GarnetServer at the start, for more details, or check this link. maybe reduce to 32m? "ObjectStorePageSize" : "1m" => this is too high, please change this to 4k. (note: we need to really update the default value here as everyone trips up with this default setting.) "ObjectStoreHeapMemorySize" : "", => please set this based on how much memory you want to use for the heap objects in the object store. "ObjectStoreIndexSize" : "16m", => see the comment on IndexSize above. maybe ok to leave as 16m. |
Beta Was this translation helpful? Give feedback.
-
Thanks, I'll try the configuration you mentioned above. |
Beta Was this translation helpful? Give feedback.
-
|
Closing as this was resolved in #1239 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
In our scenario, large amounts of data are added to the Garnet database at regular intervals (e.g., every 30 seconds, 1 minute, 2 minutes etc..), with an expiration duration of 1 minute. This results in heavy data insertion and deletion. While Redis handles this efficiently with only a few megabytes of RDB data, Garnet's memory usage keeps growing indefinitely. Even with Compaction and Revivification enabled, the Garnet server continues to consume a large amount of memory.
Compaction Settings:
"CompactionFrequencySecs" : 30,
"ExpiredObjectCollectionFrequencySecs" : 30,
"CompactionType" : "Lookup"
Revivification Settings:
"EnableRevivification" : true
Garnet.conf:
Garnet.txt
Beta Was this translation helpful? Give feedback.
All reactions