fix: increase MAX_IOVECS limit to handle large concurrent writes #1229
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Increase the MAX_IOVECS constant from 128 to 1024 to handle more concurrent IO operations. This fixes an issue where large updates (e.g. updating 1974 rows) would hang due to the in_flight_writes counter never reaching 0. The original limit of 128 concurrent operations was too low for large updates, causing some write completions to be lost when the number of concurrent writes exceeded the limit. This would result in the system hanging in the WaitAppendFrames state. By increasing the limit to 1024, we ensure that _"most"_ writes in large update operations can be properly tracked and completed. Signed-off-by: Daniel Boll <danielboll.academico@gmail.com>
Daniel-Boll
requested review from
pereman2,
jussisaurio and
penberg
as code owners
penberg
requested changes
Apr 2, 2025
| @@ -12,7 +12,7 @@ use std::sync::Arc; | |||
| use thiserror::Error; | |||
| use tracing::{debug, trace}; | |||
|
|
|||
| const MAX_IOVECS: u32 = 128; | |||
| const MAX_IOVECS: u32 = 1024; | |||
There was a problem hiding this comment.
I don't think this increase in iovecs fixes anything. It just moves the point of hanging to much higher concurrency?
However, we probably should just make this configurable by introducing an UringOpts struct and passing that to UringIO::new(). We can make the default iovecs size larger too.
There was a problem hiding this comment.
@penberg Create the `UringOpts`, is docstrings welcomed in this case?
Generated some for other methods as well
What do you think?
Introduce `UringOpts` struct for configuring io_uring backend with parameters like `max_iovecs` and `sqpoll_idle`. Add support for custom options in `UringIO` initialization. Include detailed documentation and examples. BREAKING CHANGE: `UringIO` initialization now requires options via `UringOpts` or defaults. Signed-off-by: Daniel Boll <danielboll.academico@gmail.com>
Daniel-Boll
force-pushed
the
fix/io-uring-limit
branch
from
a5bb9c9 to
a7eda7c
Compare
…-limit Signed-off-by: Daniel Boll <danielboll.academico@gmail.com>
Signed-off-by: Daniel Boll <danielboll.academico@gmail.com>
|
This pull request has been marked as stale due to inactivity. It will be closed in 7 days if no further activity occurs. |
|
This pull request has been closed due to inactivity. Please feel free to reopen it if you have further updates. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Increase the MAX_IOVECS constant from 128 to 1024 to handle more concurrent IO operations. This fixes an issue where large updates (e.g. updating 1974 rows) would hang due to the in_flight_writes counter never reaching 0.
The original limit of 128 concurrent operations was too low for large updates, causing some write completions to be lost when the number of concurrent writes exceeded the limit. This would result in the system hanging in the WaitAppendFrames state.
By increasing the limit to 1024, we ensure that "most" writes in large update operations can be properly tracked and completed.