Skip to content
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]: Fix RocksMQ Slow on consume #14612

Closed
1 task done
xiaofan-luan opened this issue Dec 30, 2021 · 1 comment · Fixed by #14614
Closed
1 task done

[Bug]: Fix RocksMQ Slow on consume #14612

xiaofan-luan opened this issue Dec 30, 2021 · 1 comment · Fixed by #14614
Assignees
Labels
kind/bug Issues or changes related a bug
Milestone

Comments

@xiaofan-luan
Copy link
Collaborator

Is there an existing issue for this?

  • I have searched the existing issues

Environment

- Milvus version:
- Deployment mode(standalone or cluster):
- SDK version(e.g. pymilvus v2.0.0rc2):
- OS(Ubuntu or CentOS): 
- CPU/Memory: 
- GPU: 
- Others:

Current Behavior

Rocks MQ consume fairly slow on consume, see the log "rocksmq consume too slowly xxx"

Expected Behavior

rocksmq should consume fairly fast because most of the time it consume only from the end of the queue, it should be always on memory table or l0 files.

however, since the value of store is very large, if we hit on disk it might be fairly slow.

Before we use prefix_extractor, which rely on the prefix is fixed length, and brings much trouble.

Thus we changed to SetIterator Upper Bound, it works fine but sometimes we see loss of data or duplicated data.

Then we changed to Iter.ValidForPrefix(), the correctness works but we saw this performance issue.

Steps To Reproduce

keep writing data and consume on rocksmq, after few hours you will see this issue.

Anything else?

SetIterator Upper Bound issue is due to go gc the upper bound array.

Iter.ValidForPrefix is slow because it always fetch one more row from rocksdb, and that row is cold and occur some extra ios

@xiaofan-luan xiaofan-luan added kind/bug Issues or changes related a bug needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Dec 30, 2021
@xiaofan-luan xiaofan-luan removed the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Dec 30, 2021
@xiaofan-luan xiaofan-luan added this to the 2.0.0-GA milestone Dec 30, 2021
@xiaofan-luan
Copy link
Collaborator Author

see also #14077

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Issues or changes related a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants