kvstreamer: perform more memory accounting #83683
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
kvstreamer: perform more memory accounting
This commit performs memory accounting for more of the internal state of
the streamer. In particular, it adds accounting for the overhead of
Result
s in the results buffer (previously, we would only account forthe size of the Get or the Scan response but not for the
Result
structitself). It also adds accounting for all slices that are
O(N)
in sizewhere
N
is the number of requests.Addresses: #82160.
Release note: None
kvstreamer: account for the overhead of each request
Previously, we didn't account for some of the overhead of Get and Scan
requests, and this commit fixes that.
Here is the list of all things that we need to account for a single Get
request:
[]roachpb.RequestUnion
) the overhead of theroachpb.RequestUnion
objectroachpb.RequestUnion_Get
objectroachpb.GetRequest
objectroachpb.GetRequest
.Previously, we only accounted for the first and the fourth items, and
now we account for all of them. Additionally, we used the
auto-generated
Size
method for the fourth item which I believerepresent the size of the serialized protobuf message (possibly
compressed - I'm not sure), but we're interested in the capacities of
the underlying slices.
Addresses: #82160.
Release note: None