sqlccl: speed up partitioning tests #21392
Conversation
|
This change is |
benesch
force-pushed
the
speed-up-part-tests
branch
from
b0d9232 to
04ab32b
Compare
benesch
force-pushed
the
speed-up-part-tests
branch
from
04ab32b to
a74aff8
Compare
| sqlDB := sqlutils.MakeSQLRunner(tc.Conns[0]) | ||
| sqlDB.Exec(t, `CREATE DATABASE data`) | ||
| sqlDB.Exec(t, `USE data`) | ||
|
|
||
| // Disabling store throttling vastly speeds up rebalancing. | ||
| sqlDB.Exec(t, `SET CLUSTER SETTING server.declined_reservation_timeout = '0s'`) |
There was a problem hiding this comment.
Hm.. is it possible to just override directly via the *Settings in the testserverargs? IIRC these gossiped updates sometimes flake since you can't wait for them to propagate.
There was a problem hiding this comment.
Overriding directly isn't a good idea as you can get that updated wiped out by Gossip updates. I think this is fine (or rather, I'll take my chances). Especially for this one it shouldn't cause a problem if it flakes? The test will take a little longer for the initial snapshots, but not for all of them.
Partitioning tests are bottlenecked on test cluster rebalancing. Make rebalancing much faster by turning down the scan interval and disabling store throttling. TestInitialPartitioning and TestRepartitioning now take under 30s combined, when previously they could take several minutes. Release note: None
benesch
force-pushed
the
speed-up-part-tests
branch
from
a74aff8 to
5c3d4ce
Compare
|
Looks like setting the ScanInterval to 1ms can starve out other stress instances. Sigh. Hopefully 100ms is a good middle ground. |
|
I looked into your acceptance flake. Looks like one node just isn't becoming live again after and in fact the cluster looks completely hosed (liveness problems, etc). Perhaps there is a race in which we restart nodes faster than their ports are propagated (so that eventually there's a disconnect)? I didn't think so, but something has to be causing this. |
|
(Either way, nothing that should block this PR) |
|
Oh, heh, I didn't even notice that acceptance test failure. A 100ms scan interval seems to have fixed the |
|
Thanks for the reviews, folks! |
Turning the ScanInterval way down shaves a minute or two off their
runtime.
Closes #21223.
Closes #21235.
Closes #21340.
Closes #21329.
Closes #21409.
Closes #21423.
Closes #21471.
Closes #21474.
Release note: None