-
Notifications
You must be signed in to change notification settings - Fork 6.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
max_suspicious_broken_parts = 10 (default) is too low #41423
Labels
Comments
den-crane
changed the title
max_suspicious_broken_parts = 10 (default is too low)
max_suspicious_broken_parts = 10 (default) is too low
Sep 16, 2022
I think, it's happens quite often with really small test/tmp tables. May be we should have another threshold about size in bytes for broken parts? |
I think the issue you're thinking happens because of
|
This was referenced Mar 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We often see complaints about startup issue
Suspiciously many (12 parts, 0.00 B in total) broken parts to remove while maximum allowed broken parts count is 10
and in 100% cases it's because of an unexpected restart and files with 0 size or parts without half of files. The maximum number that I saw in public chats or from Altinity clients is 70 broken parts.(it seems the modern hardware (ssd) + arbitrary partitioning allow to create a more parts per second than it was in 2016 when max_suspicious_broken_parts = 10 was good enough)
Personally I set max_suspicious_broken_parts = 100.
So my proposal is to increase the default to 100 or at least to 50.
The text was updated successfully, but these errors were encountered: