Enable threaded I/O on redis-cache gprd
Production Change
Change Summary
We are enabling threaded I/O on redis-cache in gprd. This was already done in gstg, see https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/12810.
Change Details
- Services Impacted - ServiceRedis
- Change Technician - @rehab
- Change Reviewer - @igorwwwwwwwwwwwwwwwwwwww
- Change Time - 09:30 UTC
- Time tracking - 120 minutes
- Downtime Component - Reads will remain available, there will be a minimal window of data loss during controlled failover.
Detailed steps for the change
Change Steps - steps to take to execute the change
Estimated Time to Complete (mins) - 105 mins
-
Merge and apply chef change -
Prepare shell cd runbooks -
Get original config value scripts/redis-config-get.sh gprd redis-cache io-threadsparallel --tag ssh redis-cache-{}-db-gprd.c.gitlab-production.internal sudo gitlab-redis-cli config get io-threads ::: 01 02 03 -
Run reconfigure script scripts/redis-reconfigure.sh gprd redis-cache -
Check that the config value was set scripts/redis-config-get.sh gprd redis-cache io-threadsparallel --tag ssh redis-cache-{}-db-gprd.c.gitlab-production.internal sudo gitlab-redis-cli config get io-threads ::: 01 02 03
Post-Change Steps - steps to take to verify the change
Estimated Time to Complete (mins) - 15 mins
-
Check CPU utilization - Dashboard
sudo pidstat -t -p $(pidof bin/redis-server) 1- (Optional) Record a profile with perf
Rollback
Rollback steps - steps to be taken in the event of a need to rollback this change
Estimated Time to Complete (mins) - 60
-
Revert and apply chef change -
Prepare shell cd runbooks -
Get original config value scripts/redis-config-get.sh gprd redis-cache io-threadsparallel --tag ssh redis-cache-{}-db-gprd.c.gitlab-production.internal sudo gitlab-redis-cli config get io-threads ::: 01 02 03 -
Run reconfigure script scripts/redis-reconfigure.sh gprd redis-cache -
Check that the config value was set scripts/redis-config-get.sh gprd redis-cache io-threadsparallel --tag ssh redis-cache-{}-db-gprd.c.gitlab-production.internal sudo gitlab-redis-cli config get io-threads ::: 01 02 03
Monitoring
Key metrics to observe
- Metric: Saturation
redis_primary_cpu- Location: https://dashboards.gitlab.net/d/redis-cache-main/redis-cache-overview?orgId=1
- What changes to this metric should prompt a rollback: Sustained increase above baseline.
Summary of infrastructure changes
-
Does this change introduce new compute instances? -
Does this change re-size any existing compute instances? -
Does this change introduce any additional usage of tooling like Elastic Search, CDNs, Cloudflare, etc?
Summary of the above
Changes checklist
-
This issue has a criticality label (e.g. C1, C2, C3, C4) and a change-type label (e.g. changeunscheduled, changescheduled) based on the Change Management Criticalities. -
This issue has the change technician as the assignee. -
Pre-Change, Change, Post-Change, and Rollback steps and have been filled out and reviewed. -
Necessary approvals have been completed based on the Change Management Workflow. -
Change has been tested in staging and results noted in a comment on this issue. -
A dry-run has been conducted and results noted in a comment on this issue. -
SRE on-call has been informed prior to change being rolled out. (In #production channel, mention @sre-oncalland this issue and await their acknowledgement.) -
Release managers have been informed (If needed! Cases include DB change) prior to change being rolled out. (In #production channel, mention @release-managersand this issue and await their acknowledgment.) -
There are currently no active incidents.