chore: cap all comparison pods at 2 CPU / 4Gi - #35
Merged
Conversation
Uniform 2 CPU / 4Gi requests/limits for every backend server in the comparison configs (oxia sizes, zookeeper, etcd, redis, tikv, consul). The previous 3 CPU / 6Gi pods binpacked poorly onto the available VM shapes (the oxia-12 scale-up churned on spot); uniform 2/4 pods pack cleanly. Scale the in-pod knobs with the container: - oxia readCacheSizeMB 3072 -> 2048 (still ~30x the 1M x 64B dataset, so reads stay cache hits) - zookeeper heapSize 3072 -> 2048 (2x the 1024 default that OOM'd on the 1M-znode keyspace; keeps the half-of-container heap ratio) Bench workers are sized per run; pass WORKER_CPU=2 WORKER_MEM=4Gi to match. Signed-off-by: Matteo Merli <mmerli@apache.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Uniform 2 CPU / 4Gi requests/limits for every backend server in the comparison configs (oxia sizes, zookeeper, etcd, redis, tikv, consul). The previous 3 CPU / 6Gi pods binpacked poorly onto the available VM shapes — the oxia-12 scale-up (12×3CPU/6Gi + workers ≈ 66 CPU / 132Gi) churned on spot nodes. Uniform 2/4 pods pack cleanly and shrink oxia-12 to a schedulable footprint.
In-pod knobs scaled with the container:
readCacheSizeMB3072 → 2048 — still ~30× the 1M×64B dataset, so reads remain cache hits.heapSize3072 → 2048 — 2× the 1024 bitnami default that OOM'd on the 1M-znode keyspace, and keeps the same half-of-container heap ratio that ran clean at 6Gi.Bench workers are sized per run; runs should pass
WORKER_CPU=2 WORKER_MEM=4Gito match.Verification
helm templaterenders checked for oxia-3 (server StatefulSet 2 CPU/4Gi;dataserver.yamldeep-mergesreadCacheSizeMB: 2048with the data dirs intact), zookeeper (ZOO_HEAP_SIZE=2048, 2/4Gi resources), and etcd (2/4Gi); nocpu: "3"/6Gi/3072remains undercomparison/.Note: results at this sizing are a new baseline — not comparable to runs from the 3 CPU / 6Gi configs.