-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[Bug]: A large number of delete operations have accumulated in Milvus. #38708
Comments
@become-nice upgrade milvus to v2.4.18 and config your milvus.yaml as follows: You can refer to it and then tuning it
|
I want to know what is complexDeleteLimitEnable mean. I see that there is a filter operation in version 2.4, which may delete a lot of data with just a few dozen bytes. In this case, will the deleteRate setting lose its original function? In version 2.2, deletion can only be performed based on the primary key id. We can clearly know the maximum number of data items allowed to be deleted per second under a certain deleteRate value, but in 2.4, how is this calculated? |
In Milvus 2.4, you can delete with an expression, which does not limit in pk only. But you can still delete entities with pk only expression that is the same behavior as 2.2. /assign @become-nice |
I want to ask what is the difference between l0 compaction and mix compaction |
If I set complexDeleteLimitEnable to false, can users still use filters to delete data? |
Yes |
Is there an existing issue for this?
Environment
Current Behavior
When I performed a large number of batch delete and write operations, I found that the compaction performance could not keep up. A large number of deltalogs were accumulated. After checking the logs, I found that the operations from half an hour ago were still being applied. When I was still performing a large number of deletion and insertion operations, the instance would quickly become uninsertable.
Why can't we restrict the user's insertion and deletion operations when the compaction performance cannot keep up? Or has the optimization been made in version 2.4?
Expected Behavior
When compaction cannot keep up, restrict users from inserting and deleting data to avoid the cluster becoming unavailable.
Steps To Reproduce
Milvus Log
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: