AWS 엔지니어, Linux 7.0에서 PostgreSQL 성능 절반으로 떨어지는 회귀 보고 — 수정도 쉽지 않은 상황

• AWS 엔지니어가 Linux 7.0 커널에서 PostgreSQL 처리량이 기존 대비 절반(0.51x)으로 떨어지는 심각한 성능 회귀를 보고함

  • 테스트 환경은 AWS Graviton4 서버, 유저스페이스 스핀락(spinlock)에서 소비되는 시간이 크게 증가한 게 원인
  • Amazon/AWS의 Salvatore Dipietro가 처리량(throughput)과 지연시간(latency) 회귀를 리눅스 커널 메일링 리스트에 공식 보고

• 범인은 Linux 7.0에서 커널 프리엠션(preemption) 모드를 단순화한 패치

  • 기존에 여러 프리엠션 모델을 지원하던 걸 Full과 Lazy 두 가지로 줄이면서, 기본값이었던 PREEMPT_NONE이 사라짐
  • 이 변경이 PostgreSQL처럼 유저스페이스 스핀락에 의존하는 워크로드를 직격으로 때림

• 회귀를 해결하기 위해 PREEMPT_NONE을 기본값으로 복원하는 패치가 제출됐지만, 원래 코드를 작성한 Peter Zijlstra가 반대 의견을 냄

  • Zijlstra의 입장: "PostgreSQL 쪽에서 RSEQ(Restartable Sequences) 타임슬라이스 확장을 사용하면 됨"
  • 즉, 커널을 되돌리는 게 아니라 PostgreSQL이 새 API에 맞춰 적응하라는 것
  • RSEQ 타임슬라이스 확장 지원도 Linux 7.0에서 함께 업스트림된 기능

• 이대로 가면 PostgreSQL이 RSEQ를 도입할 때까지 Linux 7.0 환경에서 상당한 성능 저하를 감수해야 하는 상황

  • 커널 메인테이너 vs 데이터베이스 진영 간의 "누가 고쳐야 하나" 책임 공방이 벌어지고 있는 셈

---

기술 맥락

• 리눅스 커널의 프리엠션 모델이란 건, 커널이 실행 중인 작업을 얼마나 적극적으로 중단시킬 수 있는지를 결정하는 설정이에요. PREEMPT_NONE은 "가능한 한 현재 작업을 방해하지 마"라는 모드인데, 데이터베이스처럼 긴 연산을 하는 워크로드에 유리하거든요
• 이번에 문제가 된 건, 프리엠션 모드 옵션을 줄이면서 PostgreSQL의 유저스페이스 스핀락이 커널에 의해 자주 중단되게 된 거예요. 스핀락은 "잠깐만 기다리면 풀릴 거야"라고 바쁘게 대기하는 방식인데, 이걸 잡고 있는 스레드가 선점당하면 다른 스레드들이 전부 멍하니 기다리는 상황이 발생해요
• RSEQ(Restartable Sequences)는 유저스페이스 코드가 커널에게 "이 구간은 중단하지 마"라고 힌트를 줄 수 있는 메커니즘이에요. 타임슬라이스 확장이 추가되면서, 크리티컬 섹션 실행 중에는 선점을 미루도록 요청할 수 있게 됐거든요
• 커널 메인테이너 입장에서는 코드 복잡도를 줄이기 위해 레거시 옵션을 정리한 건데, 그 여파가 가장 많이 쓰이는 DB 중 하나인 PostgreSQL에 직격탄이 된 거라 논란이 커지고 있어요. 결국 "인프라가 먼저 바뀌면 애플리케이션이 따라가야 하는가"라는 전형적인 트레이드오프 문제예요