2023-02-27: The rails_primary_sql SLI of the patroni service (`main` stage) has an apdex violating SLO: 97.42%
Current Status
Beginning around 1648 utc GitLab.com was subjected to an event which saturated the CPU for the primary database node to the tune of 86.75% at peak and about 80% generally for about 30 minutes.
Currently it is suspected that multiple invocation of a specific API endpoint was responsible for about 117 database requests which took longer than 11 seconds, far beyond the normal duration for nearly all requests ever.
I am still investigating and tracking down how and why this activity might have caused such a serious elevation in CPU on the primary database node.
Despite the wide reporting of symptoms by users in the comments in this incident issue below, almost none of the service degradation symptoms reported were related to the root cause of this incident, and instead, were caused by the root cause of this later incident: #8473 (closed)
More information will be added as we investigate the issue. For customers believed to be affected by this incident, please subscribe to this issue or monitor our status page for further updates.
📝 Summary for CMOC notice / Exec summary:
- Customer Impact:
Hundreds of user jobs failed to be picked up by a runner - Service Impact: ServicePatroni ServiceCI Runners
- Impact Duration:
1715 utc-1648 utc=less than 30 minutes - Root cause: RootCauseSaturation
A single user's API activity/Also, possibly a replica was out of date
📚 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.