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]: Querycoord set wrong watchDmchannelInfo when one partition is empty #15728

Closed
1 task done
xige-16 opened this issue Feb 24, 2022 · 2 comments
Closed
1 task done
Assignees
Labels
kind/bug Issues or changes related a bug needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Milestone

Comments

@xige-16
Copy link
Contributor

xige-16 commented Feb 24, 2022

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

If a collection has multi partitions, and some some partitions don't have been inserted. There may be two problems when loading:

  1. If some paritiotns have not been inserted, the checkpoint of the partitions has not been updated, resulting in the seekposition in the watchchannelReq received by the querynode being an older checkpoint. Then load will be slower

  2. the flushed segment list in the watchchannelReq received by the querynode are empty

Eventually, when loading, for a certain segment, querynode memory exists both the seal segment and the growing segnent, So the memory needed when loading will be double.

After the load is completed, the querynode will delete the growing segment from memory after receiving the sealedsegmentchangeinfo, and eventually the querynode memory will only have the sealed segments.

Expected Behavior

No response

Steps To Reproduce

No response

Anything else?

No response

@xige-16 xige-16 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 Feb 24, 2022
@xige-16
Copy link
Contributor Author

xige-16 commented Feb 24, 2022

/unassign @yanliang567
/unassign

@xige-16
Copy link
Contributor Author

xige-16 commented Feb 24, 2022

/assign

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 needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

3 participants