-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
kv: triage microbenchmark regressions for v24.3 #133682
Comments
I don't think the CPU regression is real. There is a fairly high variance in the test and the measurement is in microseconds/op. After running a few times with different combinations, it seems most likely that this is just test variance rather than a real issue: CPU regression:
The memory regression is real, but its due to known changes to the
|
I am not going to get to the regression I assigned myself against today. I'll be back on Monday the 10th of November to assist if necessary. Un-assigning myself in the meantime. |
Ran another bisect, pointing to 78732f6. This seems more likely. Will investigate.
From what I can tell,
|
We seem to have improved on all but Doesn't work out of the box, because some benchmarks here have been improved over the course of 24.3 development:
I'm going to focus just on
No luck there either. Seems like we overall regressed this benchmark and then improved it. Whatever improvement we made resulted in most of the variants getting better, but 3 of them still showed a slight regression overall.
Given the regression between 24.1 and master is <4% for 3 variants, and most variants of the benchmark have actually improved, I'm going to check this off. |
Make this usable with Benchdiff. Informs cockroachdb#133682 Release note: None
I bisected some of the regression in bisect result
Comparing to the commit prior, we see:
Looking at the change and the heap profile, the only thing I can weakly conclude is that the allocations here are a result of introducing a new system table. For context, the entire regression between master and 24.1 looks like:
I'll focus on the CPU regression for Bisect finished; points to 1b5c419. bisect results
I'm not convinced this isn't just "noise". On 4 different runs, I see: run 1
run 2
run 3
run 4
For any on-lookers that don't want to expand, that's 0%, 3.61%, 6.74%, 0%. Looking at the commit, and diffing the CPU profiles from the 6.74%, nothing jumps out either. |
The 20.19% increase in cockroach/pkg/raft/raftpb/raft_test.go Line 48 in b20c617
cockroach/pkg/raft/raftpb/raft_test.go Line 51 in 1b5c419
Marking the regression on that metric as expected. |
I'm still investigating since I'm using it as a learning activity,but |
Describe the problem
release-24.1 (b20c617) -> master (1b5c419); raw sheets from.
All relevant performance regressions are reflected in the sec/op metric unless otherwise specified.
pkg/kv/kvserver
ReplicaProposal
(secs/op
andallocs/op
) @andrewbaptistOptimisticEval/latches
@arulajmaniBumpSideTransportClosed
@arulajmaniStoreRangeSplit
(@stevendanna)pkg/kv/kvserver/gc
Run
(allocs/op
) @tbg1pkg/kv/kvserver/batcheval
BenchmarkRefreshRange
#134420pkg/kv/kvserver/tscache
IntervalSklAdd
@tbg2pkg/kv/kvclient/kvcoord
TruncateLoop
(secs/op
andallocs/op
) @andrewbaptistSingleRoundtripWithLatency
(secs/op
andallocs/op
) @arulajmanipkg/raft/rafttest
Proposal3Nodes
(secs/op
andallocs/op
) @iskettaneh (test-related regression)Status/members
(secs/op
andallocs/op
) @iskettaneh (Marked as expected in this issue)RawNode/two-voters-32
(allocs/op) @iskettaneh (opened this issue)OneNode-32
@nvanbenschotenTips for debugging
Benchdiff can be a useful tool for debugging. Install the tool, then follow these steps to auto-bisect the regression.
Jira issue: CRDB-43730
Footnotes
I think this is about the 5.41% more in allocs? Most other flavors of this benchmark are doing significantly better (according to this spreadsheet). This test also sets up a giant dataset and somehow takes literal ages under benchdiff on my gceworker; I think it somehow doesn't cache the dataset maybe? It takes 15m on my M1. Either way this is probably not worth seeing through, the regressed test case is 10% intents and nothing deleted, so it isn't anything that needs to be particularly fast in real life. ↩
I ran
$ git log --oneline 1b5c419 --not $(git merge-base b20c617 1b5c419) -- './pkg/kv/kvserver/tscache/*.go'
and there haven't been any code changes to this package. I ran benchdiff just to make sure and it confirmed that everything was~
. ↩The text was updated successfully, but these errors were encountered: