Skip to content

storage: decrease default kv.bulk_io_write.max_rate#36884

Merged
craig[bot] merged 1 commit intocockroachdb:masterfrom
thoszhang:reduce-max-rate
Apr 17, 2019
Merged

storage: decrease default kv.bulk_io_write.max_rate#36884
craig[bot] merged 1 commit intocockroachdb:masterfrom
thoszhang:reduce-max-rate

Conversation

@thoszhang
Copy link
Copy Markdown

@thoszhang thoszhang commented Apr 16, 2019

Previously kv.bulk_io_write.max_rate had a default value of MaxInt64, which
caused rounding problems in the rate limiter due to very small time intervals.
This lowers the default to 1 TB/s.

Fixes #36806.
(See #36806 (comment))

Release note (bug fix): The default value of kv.bulk_io_write.max_rate is now
1 TB/s, to help prevent incorrect rate limiting behavior due to rounding.

@thoszhang thoszhang requested review from a team and dt April 16, 2019 19:55
@cockroach-teamcity
Copy link
Copy Markdown
Member

This change is Reviewable

@thoszhang thoszhang requested a review from tbg April 16, 2019 19:55
Copy link
Copy Markdown
Member

@tbg tbg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was tempted to ask you to validate the byte setting, but it would be unclear what the validation is (other than saying it can't be more than 2TB or something like that). What was the underflow? A float64 can represent 1/MaxInt64 but I assume it did more math with it than that. Is that rate limiter generally wonky (as in, numerically unstable or the like)?

@tbg
Copy link
Copy Markdown
Member

tbg commented Apr 16, 2019

I just found #36806 (comment). I like to link to discussions when submitting a PR, consider doing that here too.

Previously `kv.bulk_io_write.max_rate` had a default value of `MaxInt64`, which
caused rounding problems in the rate limiter due to very small time intervals.
This lowers the default to 1 TB/s.

Release note (bug fix): The default value of `kv.bulk_io_write.max_rate` is now
1 TB/s, to help prevent incorrect rate limiting behavior due to rounding.
@thoszhang
Copy link
Copy Markdown
Author

"Underflow" isn't the right word. I thought it might have been part of the problem originally, but it's actually just a more straightforward case of an integer cast rounding a small float to 0. (I updated the commit message.)

Regarding validation, I expect that nobody will try to raise the setting past 1 TB - the goal here was just to make a minimal change so the default setting won't get the rate limiter into a bad state, but I'm open to adding it.

@dt
Copy link
Copy Markdown
Contributor

dt commented Apr 17, 2019

We should hold off on adding validation if we want to back port this.

@thoszhang
Copy link
Copy Markdown
Author

bors r+

craig bot pushed a commit that referenced this pull request Apr 17, 2019
36884: storage: decrease default kv.bulk_io_write.max_rate r=lucy-zhang a=lucy-zhang

Previously `kv.bulk_io_write.max_rate` had a default value of `MaxInt64`, which
caused rounding problems in the rate limiter due to very small time intervals.
This lowers the default to 1 TB/s.

Fixes #36806.
(See #36806 (comment))

Release note (bug fix): The default value of `kv.bulk_io_write.max_rate` is now
1 TB/s, to help prevent incorrect rate limiting behavior due to rounding.

Co-authored-by: Lucy Zhang <lucy-zhang@users.noreply.github.com>
@craig
Copy link
Copy Markdown
Contributor

craig bot commented Apr 17, 2019

Build succeeded

@craig craig bot merged commit 8f53788 into cockroachdb:master Apr 17, 2019
@thoszhang thoszhang deleted the reduce-max-rate branch April 17, 2019 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sql: zeroqps during schema change with reduced bulk_io_write.max_rate

5 participants