Tunes urgent-cpu-bound hpa and minReplicas
What does this MR do?
- We are scaling a little too aggressively, sometimes hitting our max pod count despite not using all available CPU capacity. Changing the target average CPU will pull down the level for which we scale.
- We are also scaling quickly enough that we remain undersaturated. For this, let's proceed to lower our minimum replicas to only 30.
- This leaves us with at minimum 150 available workers, which is still 10 more than what we had previously running on VM's.
Dry run results
For the gprd
sidekiq urgent-cpu-bound
shard:
- name: urgent-cpu-bound
concurrency: 5
hpa:
- targetAverageValue: 200m
- minReplicas: 40
+ targetAverageValue: 300m
+ minReplicas: 30
Addresses: gitlab-com/gl-infra/delivery#972 (closed)
Edited by John Skarbek
Merge request reports
Activity
Starting https://ops.gitlab.net pipeline: View the ops deployment pipeline for jts/tune-hpa-urgent-cpu / 675f88c7 Detected changes for gprd-cny: View the ops deployment pipeline for jts/tune-hpa-urgent-cpu / 675f88c7gitlab-cny, gitlab-cny-gitlab-chart-info, ConfigMap (v1) has changed gitlab-cny, gitlab-cny-gitlab-upgrade-check, Job (batch) has changed
Detected changes for gprd: View the ops deployment pipeline for jts/tune-hpa-urgent-cpu / 675f88c7gitlab, gitlab-sidekiq-urgent-cpu-bound-v1, HorizontalPodAutoscaler (autoscaling) has changed
mentioned in commit 7d842f80
Starting https://ops.gitlab.net pipeline: View the ops deployment pipeline for master / 7d842f80 Detected changes for gprd-cny: View the ops deployment pipeline for master / 7d842f80gitlab-cny, gitlab-cny-gitlab-chart-info, ConfigMap (v1) has changed gitlab-cny, gitlab-cny-gitlab-upgrade-check, Job (batch) has changed
Detected changes for gprd: View the ops deployment pipeline for master / 7d842f80gitlab, gitlab-sidekiq-urgent-cpu-bound-v1, HorizontalPodAutoscaler (autoscaling) has changed
Please register or sign in to reply