▲

AWS 엔지니어, Linux 7.0에서 PostgreSQL 성능이 절반으로 감소했다고 보고 – 수정이 쉽지 않을 수 있음

 (phoronix.com/news)
2P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • Linux 7.0 개발 커널에서 PostgreSQL 데이터베이스 서버의 처리량이 이전 커널 대비 약 절반 수준으로 떨어지는 심각한 성능 회귀가 Amazon/AWS 엔지니어에 의해 발견됨
  • Graviton4 서버에서 측정한 결과, Linux 7.0은 이전 커널 대비 약 0.51배의 처리량만을 제공하며, 그 원인은 유저 스페이스 스핀락에서 훨씬 많은 시간이 소비되는 것으로 밝혀짐
  • 회귀의 원인은 Linux 7.0에서 단행한 커널 선점(preemption) 모드 제한 변경으로, PREEMPT_NONE을 기본값으로 복원하는 패치가 제출되었으나 채택 가능성이 불투명한 상황
  • 원작자인 Peter Zijlstra는 커널 수정 대신 PostgreSQL이 RSEQ(Restartable Sequences) 타임 슬라이스 확장을 활용하도록 수정해야 한다는 입장을 밝힘
  • Linux 7.0 안정 버전은 약 2주 후 출시 예정이며, Ubuntu 26.04 LTS의 기반 커널로도 사용될 예정으로, PostgreSQL 적응 전까지 광범위한 성능 저하가 우려됨

문제 발견 및 규모

  • Amazon/AWS 엔지니어 Salvatore Dipietro가 PostgreSQL의 처리량 및 지연 시간 회귀를 보고
  • Graviton4 서버 기준 측정에서 Linux 7.0이 기존 커널 대비 0.51배 처리량만 제공
    • 원인은 유저 스페이스 스핀락에서 훨씬 더 많은 시간이 소비되는 것으로 확인

회귀 원인: 선점 모드 제한

  • 바이섹팅(bisecting) 결과, Linux 7.0에서 커널 선점 모드를 제한한 변경이 원인으로 특정됨
  • 해당 변경은 최신 CPU 아키텍처를 대상으로 Full 및 Lazy 선점 모드만 유지하는 방향으로 단행되었으며, Linux 7.0 스케줄러 업데이트의 일환으로 포함됨

제출된 패치와 커널 메인테이너의 반응

  • 심각한 회귀를 이유로 PREEMPT_NONE을 기본 선점 모드로 복원하는 패치가 Linux 커널 메일링 리스트에 제출됨
  • 그러나 원래 코드를 작성한 Peter Zijlstra는 해당 패치 수용에 부정적이며, 해결책은 PostgreSQL이 RSEQ(Restartable Sequences) 타임 슬라이스 확장을 활용하는 것이라고 밝힘
    • RSEQ 타임 슬라이스 확장 역시 Linux 7.0에 포함된 기능
    • Zijlstra는 "이를 통해 락 홀더 선점 노출을 제한할 수 있다"고 설명

영향 범위 및 출시 일정

  • 만약 이 입장이 유지될 경우, PostgreSQL이 업데이트되기 전까지 Linux 7.0 안정 버전에서 일부 시나리오의 PostgreSQL 성능이 크게 저하될 수 있음
  • Linux 7.0 안정 버전은 약 2주 후 출시 예정
  • Linux 7.0은 Ubuntu 26.04 LTS의 기반 커널로, 4월 말 출시 예정인 Ubuntu 26.04 LTS에도 동일한 영향이 미칠 가능성

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • Postgres 개발자인 Andres Freund의 LKML 후속 글을 읽어볼 가치가 있음

    • 성능 문제가 재현 가능한 회귀(regression) 라면, 7.0에서 새로 추가된 기능을 꺼야만 해결되는 건 이상한 상황임
    • 단일 글이 아니라, 전체 스레드를 따라가면 추가 정보가 많음
    • 7.0에서만 발생하는 회귀를 해결하려고 7.0에서 새로 도입된 저수준 기능을 강제하는 건 좋지 않음
      Linux 유지보수자들이 PostgreSQL 같은 핵심 앱을 우선 지원 대상으로 삼아야 한다는 의견임
      예전에 Fedora가 Wine 설치 시 업데이트가 막혔던 사례가 떠오름
    • “hugepages를 쓰라”는 해결책이 항상 제시되지만, 대부분의 사용자는 이를 무시함
    • ARM64 96코어 머신에서만 성능이 0.51배로 감소했고, AMD64에서는 재현되지 않았음
      즉, PostgreSQL을 최신 커널로 올리는 모든 사용자가 겪는 문제는 아님

  • 사용자 공간에서 spinlock을 커널 지원 없이 쓰는 건 성능 저하를 자초하는 일이라는 의견임

    • 나도 Postgres의 spinlock 사용을 싫어하고 점차 제거 중임
      하지만 futex 기반 락은 메모리 배리어 증가로 인해 성능 회귀가 생김
      또한 Postgres는 여전히 8바이트 원자 연산을 지원하지 않는 플랫폼을 고려해야 해서 대체가 어려움
      문제의 spinlock은 최근 제거되었고, huge pages 사용 시에는 병목이 거의 사라짐
    • spinlock을 사용자 공간에서 쓰면 “스스로 얼굴을 망치로 치는 격”이라는 비유가 나옴
    • PostgreSQL이 오래된 커널 호환성을 유지하느라 spinlock을 써왔지만, 이제는 그만둘 때라는 의견도 있음

  • “최신 커널을 프로덕션에 쓰는 사람은 없다”는 주장도 있었음
    실제로는 Ubuntu 26.04 LTS가 Linux 7.0 기반으로 곧 출시되므로 많은 사용자가 곧 쓰게 될 것임
    현재는 sysctl이 아니라 커널 패치가 필요하다는 점이 문제임

    • 그래도 최신 커널을 테스트하는 사람이 있어야 이런 문제를 조기에 발견할 수 있음
    • PostgreSQL이 영향을 받는다면, 다른 애플리케이션도 영향을 받을 가능성이 있음
    • Docker 환경에서는 호스트 커널을 공유하므로 선택권이 없다는 지적도 있음
    • 참고로 PREEMPT_NONE 옵션은 대부분의 플랫폼에서 제거되었음

  • PREEMPT_LAZY에 대한 배경은 LWN 기사에서 확인 가능함

  • “Jia Tan이 최근 커널 패치를 냈는지 확인해봤냐”는 농담성 댓글이 있었고,
    이에 “굳이 그럴 필요도 없다, 이미 취약점이 넘쳐난다”는 답글이 달림

  • PostgreSQL 18의 비동기 I/O와 병렬 쿼리 최적화가 이번 성능 저하를 상쇄할 수 있는지 궁금하다는 의견이 있었음
    관련 내용은 PostgreSQL 18 릴리스 노트에서 확인 가능함

  • PREEMPT_LAZY 같은 동적 선점 모드가 왜 필요한지 의문이라는 의견도 있었음
    일반 사용자가 얻는 이점이 불분명하다는 것임

    • 이에 대한 답글로, 대기 시간 증가 없이 처리량을 높이기 위한 설계라는 설명이 있었음
      커널이 더 명시적인 정보를 받아 스케줄링 결정을 개선할 수 있게 된다는 것임

  • FreeBSD 14와 15.0 사이에서 10% 성능 저하를 측정했는데, 이번 사례를 보니 위안이 된다는 댓글이 있었음

    • “그래도 그만큼의 기능 추가는 있었냐”는 반응이 뒤따름

  • Phoronix가 충분한 검증 없이 기사화했다는 비판도 있었음
    후속 메일에서는 벤치마크 자체가 잘못되었고, 실제로는 큰 문제가 아니라는 결론이 나왔음

    • 다만 회귀는 huge pages를 사용하지 않을 때만 발생함
      PostgreSQL에는 큰 문제가 없겠지만, huge pages를 쓸 수 없는 다른 앱에는 영향이 있을 수 있음
      그래서 단순히 무시할 일은 아니라는 의견임

  • 오래된 LKML 스레드 링크가 함께 공유되었음

답변달기