{"id":"IL-0379","org":"InfluxData","date":"2026-09-27","docs":[],"title":{"en":"InfluxDB Cloud queries in Azure West Europe slowed and timed out as storage pods fell behind and kept restarting","ko":"Azure West Europe 의 InfluxDB Cloud 에서 9월 27일부터 30일까지 쿼리가 느려지고 타임아웃됐다"},"domain":["database","azure"],"impact":{"scope":"Queries in InfluxDB Cloud Serverless on Azure West Europe were slow and timed out, with about 55% abandoned at the worst peak; writes were accepted, but new data on some partitions was not immediately queryable","users":"Customers in the Azure West Europe region","region":"Azure West Europe"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Because the storage process uses little memory and the page cache takes what is left, a page cache too small for the data being queried does not show up as memory pressure on the usual memory metrics. InfluxData now treats major page faults as a leading indicator of storage performance degradation and alerts on cache pressure before customers see it.","ko":"캐시가 모자란 상태는 메모리 지표에 드러나지 않았다. 스토리지 프로세스가 메모리를 적게 쓰고 나머지를 페이지 캐시가 차지하기 때문이다. InfluxData 는 major page fault 를 스토리지 성능 저하의 선행 지표로 본다. InfluxData 는 스토리지 엔진의 참조 누수와 상태 검사 경로의 디스크 검사가 이런 장애를 일으키는 위험 요인은 아니며, 진단과 복구 중에 눈에 띄어 조사할 만한 현상이라고 밝혔다."},"related":[],"sources":[{"url":"https://status.influxdata.com/incidents/q52cftvv6fnl","kind":"official-status","archived":null}],"summary":{"en":"In InfluxDB Cloud, all data in a cluster is stored on redundant storage pods spread over many physical nodes. The pods read time-series data through memory-mapped files, and the host operating system keeps the most used parts of those files in a page cache made of the memory the pods do not use. In Azure West Europe each pod held about 365 GB of data, and the cache on a host could not hold the data its pods were querying. Reads that would normally come from the cache became page faults served from disk. Each pod read about 90 MB/s, so a host with ten pods read roughly 990 MB/s, close to the throughput ceiling of each host.\n\nAt that ceiling, index lookups on the write path waited on disk reads, writes fell behind and pods failed their replication-lag health check. Slow disk also made health and readiness checks time out, so healthy pods were removed and restarted, and each 30 to 85 minute recovery left the partner pod alone under load and added rebuild reads. From 27 to 30 September InfluxData increased query-layer capacity, restarted pods, raised the readiness probe timeout, doubled recovery concurrency and raised a cleanup timeout to 24 hours, which stopped the forced restarts from a lost file-reference cleanup, yet the degradation returned at each morning peak. InfluxData believes this cache shortage was also the root cause of the earlier incidents on this cluster on 7, 11, 15 and 16 September.\n\nOn 30 September at 11:59 UTC analysis showed that the cache per pod was too small and that disk reads were at the host ceiling. From 12:43 UTC InfluxData raised the resource request of each storage pod so that each host held fewer pods, which gave each pod twice the memory for page cache and twice the disk throughput. Within an hour query abandonment fell from 31% to 0.1% and page faults and disk reads dropped sharply. The morning peak on 1 October had 0.06% abandonment, and the incident was declared resolved internally at 09:48 UTC.","ko":"Azure West Europe 리전의 InfluxDB Cloud 클러스터는 모든 데이터를 여러 물리 노드에 흩어진 중복 파드에 저장한다. 이 파드들은 메모리 매핑 파일로 시계열 데이터를 읽고, 호스트 운영체제는 파드가 쓰지 않는 메모리로 만든 페이지 캐시에 그 파일에서 자주 읽는 부분을 둔다. 이 리전에서는 파드 하나가 약 365 GB 를 들고 있었고, 호스트의 캐시가 파드들이 조회하는 데이터를 다 담지 못했다. 그래서 캐시에서 나와야 할 읽기가 페이지 폴트가 되어 디스크에서 읽혔다. 파드 하나가 디스크에서 약 90 MB/s 를 읽어 파드 열 개가 있는 호스트는 약 990 MB/s 에 이르렀고, 이 값은 호스트 하나의 처리량 상한에 가까웠다. 상한에 닿자 쓰기 경로의 인덱스 조회가 디스크 읽기를 기다리느라 늦어졌고, 쓰기가 밀리면서 파드가 복제 지연 상태 검사에 실패했다. 이 리전의 파드는 하루의 8.9% 를 지연 기준 밖에서 보냈고, 비슷한 다른 리전은 0.09% 였다. 가장 바쁠 때는 가장 붐비는 파티션의 두 복제본이 함께 뒤처져 쿼리 경로에서 지연이 가장 크게 드러났다. 느린 디스크 때문에 상태 검사와 readiness 검사가 타임아웃돼 정상 파드가 재시작됐고, 재시작마다 30분에서 85분 동안 짝 파드가 혼자 부하를 졌고, 재구축이 디스크 부하를 더 올렸다. 파일 참조 안전장치도 하루 50번 넘게 재시작을 일으켰다.\n\n9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울려 장애 대응이 시작됐다. 팀은 쿼리 계층 용량을 두 배로 늘리고, 파드를 재시작하고, 9월 29일 08:58 UTC 에 readiness 타임아웃을 올려 전체에 배포하고, 재시작 뒤 복구 동시성을 두 배로 늘렸다. 9월 30일 00:25 UTC 에 정리 타임아웃을 24시간으로 올리자 강제 재시작이 멈췄다. 그래도 아침마다 성능이 떨어졌다. 9월 30일 11:59 UTC 에 팀은 분석으로 파드당 캐시 용량이 너무 작고 디스크 읽기가 호스트 상한에 닿았다는 것을 밝혔다. 12:43 UTC 에 스토리지 파드의 자원 요청을 올려 호스트마다 파드 수를 줄이고 파드를 더 많은 노드에 펼치는 배포를 시작했다. 파드마다 페이지 캐시용 메모리와 디스크 처리량이 두 배가 됐고, 1시간 안에 쿼리 중단 비율이 31% 에서 0.1% 로 떨어졌다. 10월 1일 아침 사용량이 몰린 시간의 중단 비율은 0.06% 였고, 09:48 UTC 에 내부에서 해결을 선언했다. InfluxData 는 이 상태가 앞서 9월 7일, 11일, 15일, 16일에 난 장애 모두의 근본 원인이었다고 본다."},"trigger":null,"severity":"unknown","symptoms":["high-latency","intermittent-timeouts","replication-lag","readiness-probe-failures"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"A query queue depth alert fired at 22:58 UTC on 27 September and an incident was opened.","ko":"9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울려 장애 대응이 시작됐다."},"components":["database","database-replication","health-probe","pod-scheduling"],"root_cause":"capacity","remediation":[{"text":{"en":"Doubled query-layer capacity","ko":"쿼리 계층 용량을 두 배로 늘렸다."}},{"text":{"en":"Restarted stuck storage pods one at a time","ko":"9월 28일 아침에 멈춘 스토리지 파드를 하나씩 재시작했다."}},{"text":{"en":"Raised the readiness probe timeout and rolled it out fleet-wide","ko":"9월 29일 08:58 UTC 에 readiness 검사 타임아웃을 올려 전체에 배포했다."}},{"text":{"en":"Doubled recovery concurrency after a restart","ko":"재시작 뒤 복구 동시성을 두 배로 늘렸다."}},{"text":{"en":"Raised the cleanup timeout to 24 hours, which stopped the forced restarts","ko":"9월 30일 00:25 UTC 에 정리 타임아웃을 24시간으로 올려 안전장치가 일으키던 강제 재시작을 멈췄다."}},{"text":{"en":"Raised each storage pod's resource request so each host held fewer pods, doubling page cache memory and disk throughput per pod","ko":"스토리지 파드마다 자원 요청을 올려 호스트에 올라가는 파드 수를 줄였고, 파드마다 페이지 캐시용 메모리와 디스크 처리량이 두 배가 됐다."}}],"action_items":[{"text":{"en":"Add warning alerts for page-fault rate, cache coverage, disk reads on storage volumes and query abandonment","ko":"페이지 폴트 비율, 캐시 커버리지, 스토리지 볼륨의 디스크 읽기, 쿼리 중단 비율에 경고 알림을 더했다. 알림은 캐시 압박이 고객에게 보이기 전에 울리도록 만들었다."}},{"text":{"en":"List major page faults in the runbooks as a leading indicator of storage performance degradation, with the relief valves that can be tuned","ko":"런북에 major page fault 를 스토리지 성능 저하의 선행 지표로 적고, 조정할 수 있는 완화 설정을 자세히 적었다."}},{"text":{"en":"Keep tracking down the storage-engine reference leak","ko":"스토리지 엔진의 참조 누수를 계속 추적한다."}},{"text":{"en":"Move the disk check out of the health path","ko":"디스크 검사를 상태 검사 경로에서 뺀다."}}],"contributing":["monitoring-blind-spot","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"From the evening of 27 September 2026 (UTC), InfluxDB Cloud customers in Azure West Europe saw slow queries and query timeouts, and a query queue depth alert fired at 22:58 UTC. Writes were accepted the whole time, but new data on some partitions could not be queried right away.\n\nThe degradation came back at each morning peak. On 28 September storage pods fell behind on writes and failed health checks; on 29 September throughput seemed to recover and then 36% of queries were abandoned; on 30 September about 55% were abandoned. Pods in the region spent 8.9% of the day past the replication-lag threshold, against 0.09% in a comparable region, and at peak both replicas of the busiest partitions fell behind at the same time.\n\nMemory looked normal on every metric InfluxData monitored, because the storage process uses little memory and the host page cache takes the rest, so a cache shortage did not show as memory pressure. Slow disk made health and readiness checks time out, so healthy pods were taken out of rotation and restarted; each restart took 30 to 85 minutes to recover, while the pod's partner carried the load alone and the rebuild added more disk load. A file-reference safeguard also forced more than 50 pod restarts a day, where the normal number is 0.\n\nDoubling query-layer capacity, restarting pods, raising readiness and cleanup timeouts and doubling recovery concurrency cleared many warning signs but did not remove the cause. A controller lock, a per-disk limit and the load of a single tenant were examined and ruled out. Earlier incidents on the same cluster on 7, 11, 15 and 16 September had shown the same symptom with different triggers.","ko":"9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울렸다. Azure West Europe 리전 고객의 쿼리가 느려지고 타임아웃됐다. 쓰기는 계속 받았지만 일부 파티션에서는 새 데이터를 바로 조회할 수 없었다.\n\n증상은 아침 사용량이 몰릴 때마다 심해졌다. 9월 28일 07:00 UTC 에 스토리지 파드가 쓰기를 따라가지 못하고 복제 지연 상태 검사에 실패했다. 9월 29일에는 쿼리의 36% 가, 9월 30일 아침에는 약 55% 가 중단됐다.\n\n메모리 사용량은 InfluxData 가 감시하는 모든 지표에서 정상으로 보였다. 스토리지 프로세스는 메모리를 적게 쓰고 남는 메모리는 페이지 캐시가 차지하므로, 캐시가 모자라도 메모리 압박이나 부족으로 드러나지 않았다.\n\n디스크가 느려지자 상태 검사와 readiness 검사가 타임아웃됐고, 정상인 파드가 서비스에서 빠지고 재시작됐다. 재시작한 파드는 회복하는 데 한 번에 30분에서 85분이 걸렸다. 그동안 짝 파드가 혼자 부하를 졌고, 재구축이 디스크 부하를 더 올렸다. 파일 참조를 지키는 안전장치도 하루에 50번 넘게 파드를 재시작시켰다. 정상이라면 0번이다.\n\n팀은 처음에 쿼리 계층 용량을 늘렸지만 효과가 오래가지 않았다. 멈춘 파드를 하나씩 재시작했고, readiness 타임아웃과 정리 타임아웃을 올렸고, 재시작 뒤 복구 동시성을 두 배로 늘렸다. 컨트롤러 잠금, 디스크당 한도, 한 테넌트의 부하는 원인 후보에서 뺐다. 이 조치들은 여러 이상 신호를 없앴지만 근본 원인을 풀지는 못했다.\n\n이 클러스터에서 9월 7일, 11일, 15일, 16일에 난 장애도 촉발 요인은 달랐지만 같은 증상을 보였다."},"updated_at":"2026-11-14T12:34:03.063706Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0379","org_slug":"influxdata"}