When calling the drop_collection() to delete a table, why is memory not released?
How could milvus free up the memory space occupied by the deleted collection?
Because Milvus uses LRU caching strategy, memory occupied by deleted
collection doesn't be released immediately.
Deleted data in memory
could be replaced by new data when the cache is full. Otherwise, you
could try to restart Milvus to free up memory.
Related
I want to understand when a cache is created with native persistence enabled, will it store the data in the defined data region/RAM and in the disk at the same time? Is there any way I can restrict the disk utilization for storing the data?
Additionally, in a cluster of 3 due to any reason the disk got full for one of the nodes and there is not enough memory available, what will be the impact on the cluster?
Yes, data will be stored both in RAM and on the disk. I does not have to fit in RAM at the same time.
If you run out of disk space, your persistent store will likely be corrupted.
I'm looking at Redis backed up rdb files for a web application. There are 4 such files (for 4 different redis servers working concurrently), sizes being: 13G + 1.6G + 66M + 14M = ~15G
However, these same 4 instances seem to be taking 43.8GB of memory (according to new relic). Why such a large discrepancy between how much space redis data takes up in mem vs disk? Could it be a misconfiguration and can the issue be helped?
I don't think there is any problem.
First of all, the data is stored in compressed format in rdb file so that the size is less than what it is in memory. How small the rdb file is depends on the type of data, but it can be around 20-80% of the memory used by redis
Another reason your memory usage could be more than the actual usage(you can compare the memory from new relic to the one obtained from redis-cli info memory command) is because of memory fragmentation. Whenever redis needs more memory, it will get the memory allocated from the OS, but will not release it easilyly(when the key expires or is deleted). This is not a big issue, as redis will ask for more memory only after using the extra memory that it has. You can also check the memory fragmentation using redis-cli info memory command.
I am new to redis, So please bear with me. Lets say I have configured a redis to have a maxmemory of 50mb, and I set eviction policy to allkeys-lru. And then I keep inserting and querying data. When the process memory gets to 50mb it starts to evict least recently used items.
My questions is do the evicted items persist on disk or are they lost for ever ? I mean if I do a GET for an evicted key, what do I get. Does redis fetch it from disk ?
Evicted is gone. With redis, nothing is on disk that isn't also in memory. (Technically, there will still probably be traces of it for some time, but that's just implementation details. As far as the data model is concerned, it's been deleted, and a GET won't find it.)
I am facing some scaling issues with my redis instances and was wondering if there's a way to configure redis to save data only to disk (and not hold it in memory). That way I could just increase disk space and not RAM.
Right now my instances are getting stuck and just hang when they reach the memory limit.
Thanks!
No - Redis, atm, is an in-memory database. That means that all data that it manages resides first and foremost in RAM.
Based on the
http://redis.io/topics/faq
Redis is an in-memory but persistent on disk database.
So may I know redis save key/value in memory or in disk? or both?
When writing value in Redis, it write into memory and disk at the same time?
Thanks for the concept.
depending on how you configure it, redis can periodically back up the existing state to disk, but otherwise, everything is in memory.
Redis will atomically snapshot its memory state to disk if so configured. See this part of the docs for more info:
http://redis.io/topics/persistence
So you can have different levels of durability. For the most part, when you get a key, it is out of memory and when you set a key it is also in memory. The data is written to disk independently of read/write operations.