-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
colexecdisk: limit number of FDs used by a single disk-backed op #91785
Conversation
This commit fixes an oversight in how we're computing the number of file descriptors that a single disk-backed operator can use. Previously, we would start the calculation at 1/16 of the node-wide limit, regardless of what that comes down to. If an operator cannot acquire the FDs, we have a hint suggesting to increase that node-wide limit, but then it wouldn't actually do much - the node would still support the same number of concurrent disk-spilling queries. This is now fixed by capping the number at 16 (which is the number that an operator gets with the default limit value). I don't think there is much upside in going higher - it seems more important to support higher concurrency of disk-spilling queries rather than to speed up a smaller number of queries by a percent. Release note: None
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a convenient way to test that this increases the concurrency limit for disk-spilling queries? Also, do you think it would be possible to dynamically adjust this cap according to the amount of contention for FDs?
Reviewable status:
complete! 1 of 0 LGTMs obtained (waiting on @cucaroach)
I confirmed manually that this increases the concurrency, but a unit test for this would be quite annoying to write, and I don't think it's worth it. Improving the usage of the FDs by dynamically adjusting the target number is a good idea - tracked in #91784, but I don't think it's a high priority issue since no user has complained about this before, thus I put it straight into the backlog. TFTR! bors r+ |
bors r+ |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from 6560982 to blathers/backport-release-22.1-91785: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 403 Resource not accessible by integration [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.1.x failed. See errors above. error creating merge commit from 6560982 to blathers/backport-release-22.2-91785: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 403 Resource not accessible by integration [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.2.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan. |
This commit fixes an oversight in how we're computing the number of file descriptors that a single disk-backed operator can use. Previously, we would start the calculation at 1/16 of the node-wide limit, regardless of what that comes down to. If an operator cannot acquire the FDs, we have a hint suggesting to increase that node-wide limit, but then it wouldn't actually do much - the node would still support the same number of concurrent disk-spilling queries. This is now fixed by capping the number at 16 (which is the number that an operator gets with the default limit value). I don't think there is much upside in going higher - it seems more important to support higher concurrency of disk-spilling queries rather than to speed up a smaller number of queries by a percent.
Addresses: #91784.
Epic: CRDB-20535
Release note: None