{"id":"IL-0206","org":"GitLab","date":"2022-04-25","docs":["https://gitlab.com/gitlab-com/gl-infra/chef-repo/-/merge_requests/1679","https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/15628"],"title":{"en":"Consul agents in GitLab.com's GKE pods were repeatedly OOM-killed, so the Rails pods lost database replica discovery and sent every query to the primary","ko":"GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다."},"domain":["kubernetes","gcp"],"impact":{"scope":"All of GitLab.com: intermittent site slowness and unusually delayed asynchronous work such as pipeline creation and import/export","users":"All GitLab.com users during the interval","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When the local Consul agent that Rails uses for database service discovery keeps dying, Rails does not fail; it sends every query to the last known primary. What engineers saw was database saturation and slow background jobs, which pointed the investigation first at a recent pgbouncer pool change. The memory limit of the Consul agent in every pod therefore decided the load on the primary database.","ko":"파드 안에서 함께 도는 Consul 에이전트의 메모리 한도가 모자라자 서비스 디스커버리가 끊겼고, 그 영향이 데이터베이스 primary 포화와 사이트 전체의 지연으로 번졌다. 처음 의심한 pgbouncer 풀 변경과 다음 날 별개로 보였던 오류율 상승이 모두 같은 원인으로 이어졌다. 메모리 한도를 올린 것은 임시 조치였고, Consul 의 메모리 급증이 정상 동작인지 GitLab 설정 탓인지는 아직 조사해야 했다."},"related":[],"sources":[{"url":"https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6907","kind":"github","license":"unknown","archived":null}],"summary":{"en":"Every GitLab.com pod on GKE runs a Consul agent, which the Rails application uses to discover which PostgreSQL databases are healthy, up-to-date replicas. Under certain circumstances the agent's memory demand spikes, and with a pod memory limit of 500MB the agent was killed again and again. Without a working Consul agent, the Rails pods (web, api, git and websockets) kept failing to discover replicas and fell back to sending all their queries to the last known primary database. The primary saturated, and Sidekiq processing and the whole site slowed down intermittently on 2022-04-25 and 2022-04-26.\n\nDuring the first incident the team worked from a different hypothesis: that a pgbouncer pool reduction made on 2022-04-21 had saturated connections. The plan was to raise the per-user connection limit for the gitlab database user and the pgbouncer backend pools for the main database, and to consider rolling back the CI feature flag from 50%. Saturation and slowness dropped and the incident was marked mitigated, but the elevated error rate in the early hours of 2022-04-26 turned out to be related, and further investigation tied both events to the Consul OOM kills.\n\nAs a temporary fix, the pod memory limits were raised from 500MB to 1GB so the Consul agents keep running through a spike. The team planned to watch the agents with the new limit and to find out whether the spikes are expected Consul behaviour or come from GitLab's configuration.","ko":"2022-04-25 와 2022-04-26 에 GitLab.com 전체가 간헐적으로 느려졌다. GKE 의 각 파드에는 Consul 에이전트가 함께 돌고, Rails 는 이 에이전트로 쓸 수 있는 PostgreSQL 복제본을 찾는다. Consul 에이전트는 특정 상황에서 메모리 수요가 급증했고, 메모리가 모자라면 OOM kill 로 빠르게 거듭 죽었다.\n\nmsmiley 의 분석에 따르면 Consul 에이전트가 동작하지 않자 web, api, git, websockets 의 Rails 파드는 어떤 PostgreSQL 데이터베이스가 정상이고 최신 상태인 복제본인지 거듭 알아내려다 실패했다. 서비스 디스커버리가 안 되자 기존 Rails 파드는 모든 쿼리를 마지막으로 알던 primary 로 보냈다. 읽기 트래픽이 primary 에 몰려 포화됐고, 그 때문에 Sidekiq 처리가 늦어졌다. 팀은 근본 원인이 #6909, #6910 과 같다고 정리했다.\n\n대응 초기에는 2022-04-21 의 pgbouncer 풀 크기 축소를 원인으로 보았다. 16:13 에 gitlab 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용했다. 근본 원인을 찾은 뒤에는 임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올렸다. Consul 에이전트가 메모리를 갑자기 더 써도 계속 돌 수 있게 하려는 조치였다."},"trigger":{"en":"The Consul agent in GitLab.com's GKE pods had memory demand spikes that did not fit in the pods' 500MB memory limit, and the agent was killed again and again.","ko":"GKE 파드 안의 Consul 에이전트가 특정 상황에서 메모리를 갑자기 많이 요구했고, 쓸 수 있는 메모리가 없어 Consul 프로세스가 죽었다. 당시 파드 메모리 한도는 500MB 였다."},"severity":"unknown","symptoms":["high-latency","database-overloaded","oom-killed","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"An engineer declared the incident in Slack at 15:13 UTC after the Sidekiq Apdex dropped; the second event was found when monitoring detected an elevated error rate at 01:21 UTC on 2022-04-26.","ko":"2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. 다음 날 01:21 UTC 에는 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다."},"components":["memory-limit","service-discovery","database"],"root_cause":"capacity","remediation":[{"text":{"en":"planned at 16:13 to raise the per-user connection limit for the gitlab database user and the pgbouncer backend pools for the main database; changes were applied at 17:26 and confirmed at 17:47","ko":"16:13 에 gitlab 데이터베이스 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용해 17:47 에 적용을 확인했다."}},{"text":{"en":"raised the pod memory limits from 500MB to 1GB so the Consul agents survive memory spikes","ko":"임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올려 Consul 에이전트가 메모리 급증 때도 계속 돌 수 있게 했다."}}],"action_items":[{"text":{"en":"Monitor the Consul agents on GKE pods to see whether the 1GB memory limit keeps them healthy","ko":"메모리 한도를 1GB 로 올린 것으로 충분한지 GKE 파드의 Consul 에이전트를 지켜본다."}},{"text":{"en":"Investigate the Consul memory demand spikes and what can be done beyond raising the hard memory limit","ko":"Consul 의 메모리 수요 급증을 조사해 하드 메모리 한도를 올리는 것 말고 개선할 방법이 있는지 찾는다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"On 2022-04-25 the Sidekiq Apdex (the share of background jobs that finish within a target time) dropped, and an engineer declared an incident in Slack at 15:13 UTC. Users saw intermittent slowness across GitLab.com, and asynchronous work such as pipeline creation and import and export took unusually long.\n\nThe first suspect was a pgbouncer change made on 2022-04-21 that had reduced connection pool sizes. At 16:23 the working hypothesis was that this reduction had saturated database connections; the team also looked at other recent deploys and at a feature flag rollout at 50% for CI phase 4. The Sidekiq queue had been in a bad state at 15:33 but had recovered by 16:03, and one engineer pointed out that the saturation metric was slightly incorrect, so saturation might be lower than it looked.\n\nThe incident was marked mitigated at 17:08 because saturation and site slowness had dropped, and changes were applied at 17:26 (the timeline does not list them). At 01:21 UTC on 2022-04-26 monitoring detected an elevated error rate, first declared as a separate incident and later tied to the same cause. Further investigation found OOM kills on the GKE nodes: under certain circumstances the Consul agent in each pod had a spike in memory demand, and when the memory was not available it was killed rapidly and repeatedly.","ko":"2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. Apdex 는 목표 시간 안에 끝난 작업의 비율로 만족도를 나타내는 지표다. 사용자는 사이트가 간헐적으로 느려지는 것을 겪었고, 파이프라인 생성이나 가져오기와 내보내기 같은 비동기 작업이 평소보다 오래 걸렸다.\n\n대응팀은 처음에 데이터베이스 연결 포화를 의심했다. 2022-04-21 에 pgbouncer 변경이 있었다는 보고가 나왔고, Sidekiq 대기열은 15:33 에 나빴다가 회복된 상태였다. 16:23 에 팀이 세운 가설은 chef-repo MR 1679 가 pgbouncer 풀 크기를 줄여 연결이 포화됐다는 것이었다. 팀은 main 데이터베이스의 풀 크기를 늘리고, CI 쪽 포화가 그대로면 CI phase 4 기능 플래그의 롤아웃 비율을 낮추기로 했다. 16:29 에 msmiley 는 포화 지표가 조금 부정확해서 실제로는 생각만큼 포화되지 않았을 수 있다고 지적했다. 16:36 에는 다른 장애를 맡던 사람들이 자기 문제가 이 장애에서 비롯됐다고 결론 내렸다.\n\n17:08 에 포화 수준이 크게 내려가고 사이트 지연이 멈추자 장애 상태를 완화됨으로 바꿨다. 그러나 2022-04-26 01:21 에 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다. 처음에는 별개 문제로 보였지만 분석해 보니 같은 원인이었다.\n\n추가 조사에서 원인은 GKE 노드의 OOM kill 로 드러났다. GKE 파드마다 Consul 에이전트가 함께 도는데, 이 에이전트는 특정 상황에서 메모리 수요가 갑자기 늘었다. 그만큼의 메모리를 얻지 못하면 Consul 프로세스는 빠르게 거듭 죽었다."},"updated_at":"2026-11-10T00:00:41.102221Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0206","org_slug":"gitlab"}