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

Fix queue rate limiting busy loop #3111

Merged
merged 4 commits into from
Jul 22, 2022

Conversation

yycptt
Copy link
Member

@yycptt yycptt commented Jul 18, 2022

What changed?

  • Consume ratelimiting token from host level rate limiter first and then the shard level one.
  • Check rescheduler size after ratelimiting check

Why?

  • Avoid unnecessary ratelimiter reserve & cancel (for shard level ratelimiter)
  • Avoid unnecessary dynamic config loading/checking

How did you test it?

Potential risks

Is hotfix candidate?

  • yes

@yycptt yycptt requested a review from yiminc July 18, 2022 17:21
@yycptt yycptt requested a review from a team as a code owner July 18, 2022 17:21
@@ -414,12 +414,14 @@ func newQueueProcessorRateLimiter(
) quotas.RateLimiter {
return quotas.NewMultiRateLimiter(
[]quotas.RateLimiter{
// consume from host rate limiter as it's usually the one throttles the traffic
// and avoid unnecessary consume and cancel on shard level rate limiter
hostRateLimiter,
Copy link
Member

Choose a reason for hiding this comment

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

will one rogue shard exhaust all host quota?

Copy link
Member Author

Choose a reason for hiding this comment

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

My understanding is if later ratelimiter (the shard level one) can't pass, previous reservations will be cancelled.
https://github.com/temporalio/temporal/blob/master/common/quotas/multi_rate_limiter_impl.go#L106

Copy link
Member

Choose a reason for hiding this comment

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

Please test to verify.

Copy link
Member Author

Choose a reason for hiding this comment

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

My local test shows it works fine. But theoretically one rogue shard can still affect others since other shard can try to get a host token before the rouge shard cancels it. So I reverted the change here to be safe.

The busy loop issue is still fixed.

@@ -414,12 +414,14 @@ func newQueueProcessorRateLimiter(
) quotas.RateLimiter {
return quotas.NewMultiRateLimiter(
[]quotas.RateLimiter{
// consume from host rate limiter as it's usually the one throttles the traffic
// and avoid unnecessary consume and cancel on shard level rate limiter
hostRateLimiter,
Copy link
Member

Choose a reason for hiding this comment

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

Please test to verify.

@yycptt yycptt changed the title Improve queue rate limiting Fix queue rate limiting busy loop Jul 22, 2022
@yycptt yycptt merged commit 85a5f1e into temporalio:master Jul 22, 2022
@yycptt yycptt deleted the queue-ratelimit-improve branch July 22, 2022 19:17
alexshtin pushed a commit that referenced this pull request Jul 29, 2022
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.

None yet

2 participants