Backport of core: limit job GC batch size to match other GC batches into release/1.10.x #26977
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.
Backport
This PR is auto-generated from #26974 to be assessed for backporting due to the inclusion of the label backport/1.10.x.
The below text is copied from the body of the original PR.
In the core scheduler we have several object types where we can delete them by ID. We batch up to 7281 UUIDs because this works out to be about 256 KiB per request, which is well below the maximum Raft log entry size we want to have. When we GC jobs we use this same constant to size the batch, but the request body is not a list of UUIDs but instead a map of namespaced job IDs to a pointer to a struct. This pushes the batch size into 746 KiB (assuming UUID-sized job names), which is going to impact performance if GC happens during large volumes of short-lived dispatch work where users may be GC'ing jobs frequently.
Limit the batch size for
JobBatchDeregisterRequestto roughly the same size as the requests that are lists of UUIDs.Ref: https://hashicorp.atlassian.net/browse/NMD-1041
Contributor Checklist
changelog entry using the
make clcommand.ensure regressions will be caught.
and job configuration, please update the Nomad website documentation to reflect this. Refer to
the website README for docs guidelines. Please also consider whether the
change requires notes within the upgrade guide.
Reviewer Checklist
backporting document.
in the majority of situations. The main exceptions are long-lived feature branches or merges where
history should be preserved.
within the public repository.
Changes to Security Controls
Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.
Overview of commits