-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
--consolidator-query-waiter-cap to set the max number of waiter for consolidated query #17244
base: main
Are you sure you want to change the base?
Conversation
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
eac658f
to
b08fc4d
Compare
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.
This would also require addition to summary notes for v22 over https://github.com/vitessio/vitess/blob/main/changelog/22.0/22.0.0/summary.md
You can see v21 summary notes to see the template to add new configuration to release notes
Website docs would also need an update https://vitess.io/docs/22.0/user-guides/configuration-advanced/query-consolidation/ |
2e429b6
to
86df77e
Compare
Updated. |
Hi @harshit-gangal This is not in this repo, is it? |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #17244 +/- ##
==========================================
- Coverage 67.52% 67.51% -0.02%
==========================================
Files 1581 1581
Lines 253948 253958 +10
==========================================
- Hits 171480 171454 -26
- Misses 82468 82504 +36 ☔ View full report in Codecov by Sentry. |
48f184e
to
7cb8366
Compare
6739ea6
to
8a5715e
Compare
Pushed new solution to use absolute count. |
3317e4a
to
2d8cf24
Compare
@@ -1014,6 +1016,7 @@ var defaultConfig = TabletConfig{ | |||
Consolidator: Enable, | |||
ConsolidatorStreamTotalSize: 128 * 1024 * 1024, | |||
ConsolidatorStreamQuerySize: 2 * 1024 * 1024, | |||
ConsolidatorQueryWaiterCap: 0, |
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.
nit: this can be ignored to be kept in default config for 0
as default
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.
I dropped this line and use 0 as default in the flag.
waiterCap := qre.tsv.config.ConsolidatorQueryWaiterCap | ||
if waiterCap == 0 || c.WaiterCountOfTotal() <= waiterCap { | ||
qre.logStats.QuerySources |= tabletenv.QuerySourceConsolidator | ||
startTime := time.Now() | ||
q.Wait() | ||
qre.tsv.stats.WaitTimings.Record("Consolidations", startTime) | ||
} |
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.
Adding the waiter in Record
is too late. As the wait is already complete in q.Wait()
.
Post that q.Result()
returns the stored result.
c.WaiterCountOfTotal() <= waiterCap
- This check will allow concurrent threads to go through without respecting the limit.
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.
Hi @harshit-gangal Could you please let me know if I understand correctly regarding your concern.
c.WaiterCountOfTotal() <= waiterCap - This check will allow concurrent threads to go through without respecting the limit.
-
Same query won't run concurrently, because q is a same *pendingResult object
-
Different queries when run concurrently (for those following same queries), this solution uses totalWaiterCount and only record those queries that use Wait() for *pendingResult. For example, if there are 2 different queries, and:
-- select a from A (1 running, 100 waiting)
-- select b from B (1 running, 100 waiting)
Then totalWaiterCount is 100+100=200, I added testCase on this, which is concurrently update totalWaiterCount and verify above theory is correct also verify no data race when on concurrent. -
Uniq queries should only enter
if original {...}
path, so it does not runc.WaiterCountOfTotal() <= waiterCap
check.
c.WaiterCountOfTotal() <= waiterCap - This check will allow concurrent threads to go through without respecting the limit.
WaiterCountOfTotal() is a concurrent safe, so it should be respected the limit.
func (co *consolidator) WaiterCountOfTotal() int64 {
return atomic.LoadInt64(co.totalWaiterCount)
}
Adding the waiter in Record is too late. As the wait is already complete in q.Wait().
Post that q.Result() returns the stored result.
Record
is already used to increase the count of query, for queries passed c.WaiterCountOfTotal() <= waiterCap
check, seems a good space to increase totalWaiterCount as well.
c526b3a
to
8e62c33
Compare
changelog/22.0/22.0.0/summary.md
Outdated
@@ -7,6 +7,9 @@ | |||
- **[Prefer not promoting a replica that is currently taking a backup](#reparents-prefer-not-backing-up)** | |||
- **[VTOrc Config File Changes](#vtorc-config-file-changes)** | |||
|
|||
- **[Minor Changes](#minor-changes)** | |||
- **[VTTablet](#vttablet)** | |||
- [VTTablet: New ResetSequences RPC](#vttablet-consolidator-query-waiter-cap) |
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.
VTTablet: New ResetSequences RPC
-> Query Consolidation Waiter Cap
if waiterCap == 0 || c.WaiterCountOfTotal() <= waiterCap { | ||
qre.logStats.QuerySources |= tabletenv.QuerySourceConsolidator | ||
startTime := time.Now() | ||
q.Wait() |
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.
The waiter count increases on calling the q.Wait()
method.
If you run 10s or 100s of request, they can still pass the check c.WaiterCountOfTotal() <= waiterCap
before any new waiter not getting consolidated.
A concurrent test will help test if the waiter count exceeds the maximum allowed waiter.
I think the better place to update the wait counter will be in create
call
404ac98
to
2926cb0
Compare
Signed-off-by: Jun Wang <[email protected]>
2926cb0
to
e5cdf1a
Compare
Description
This PR proposed to use config ConsolidatorQueryWaiterCap to set the max number of clients Wait() for all consolidated queries, more same queries will fall back to use getConn() where is protected by connection pools.
With configureable ConsolidatorQueryWaiterCap (default to 0 means unlimit, user can adjust this value accordingly), when properly set would help to prevent when the Result of first query been returned, same Result would be sent concurrently to large number of clients, cause memory abruptly went high.
Related Issue(s)
Issue: #17243
Documentation: vitessio/website#1900
Checklist
Deployment Notes