[scd] Change the subcription locking mechanism to a simple, shared lock. - #1363
Conversation
ede5c74 to
015fcaf
Compare
| ## The SCD global lock option | ||
|
|
||
| !!! danger | ||
| All DSS instances in a DSS pool must use the same value for this option. Mixing will result in dramatically lower performance. |
There was a problem hiding this comment.
IMO there isn't enough safeguards or mitigation that this does not happen. At least IMO we want some visibility, e.g. expose this configuration flag on the _aux interface?
cc @BenjaminPelletier
There was a problem hiding this comment.
From InterUSS weekly:
- solution to this should not take a large effort
- failing fast is OK
- addressing this through doc only is OK
- exposing through aux interface is OK
There was a problem hiding this comment.
I added the info in the aux interface
There was a problem hiding this comment.
Then, since it is exposed, maybe it would makes sense adding some test case in monitoring ensuring the values are consistent across the instances?
There was a problem hiding this comment.
Mmm I'm not sure it's worth the hassle of having a full validation for that, as we may have better solutions in the future (e.g. with crdb support dropped) and that will only affect performances, in 'high load' cases.
64207a4 to
bb6050b
Compare
mickmis
left a comment
mickmis
left a comment
There was a problem hiding this comment.
LGTM modulo downfrom entry
de42be0 to
a9043fc
Compare
|
NB: CI failure should be fixed with #1374 |
a9043fc to
da41267
Compare
|
Merging since approved by @mickmis and comments addressed. |
3 participants
This PR proposes a new method of locking subscriptions, by having a shared lock used for all subscriptions, instead of locking all rows.
See #1311 (comment) for graphs and details about the behavior change.
I added documentation in operations/performances, expecting #1362 to reuse it as well.