2023-03-15: SidekiqServiceShardLowUrgencyCpuBoundErrorSLOViolation
Current Status
The query that looks for the runner machine associated with a build is not specifying a partition_id. Since the primary key is defined as (partition_id, build_id), the correct index is not being used for the lookups, causing performance issues. Adding a partition_id filter to the query fixes the performance problem. Having it defined the other way around (build_id, partition_id) should not have cause this problem when filtering only by build_id.
A feature flag was added around the affected code path, and the load is expected to get back to normal once it hits production.
An issue exists to patch Rails 7 to propagate the partition_id value in relationships, which should land soon when we complete our migration to Rails 7.
📚 References and helpful links
Recent Events (available internally only):
- Feature Flag Log - Chatops to toggle Feature Flags Documentation
- Infrastructure Configurations
- GCP Events (e.g. host failure)
Deployment Guidance
- Deployments Log | Gitlab.com Latest Updates
- Reach out to Release Managers for S1/S2 incidents to discuss Rollbacks and/or Hot Patching | Rollback Runbook | Hot Patch Runbook
Use the following links to create related issues to this incident if additional work needs to be completed after it is resolved:
- Corrective action ❙ Infradev
- Incident Review ❙ Infra investigation followup
- Confidential Support contact ❙ QA investigation
Note: In some cases we need to redact information from public view. We only do this in a limited number of documented cases. This might include the summary, timeline or any other bits of information, laid out in out handbook page. Any of this confidential data will be in a linked issue, only visible internally. By default, all information we can share, will be public, in accordance to our transparency value.