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

> Clean Markdown view of GeekNews topic #28241. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28241](https://news.hada.io/topic?id=28241)
- GeekNews Markdown: [https://news.hada.io/topic/28241.md](https://news.hada.io/topic/28241.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-06T09:50:05+09:00
- Updated: 2026-04-06T09:50:05+09:00
- Original source: [phoronix.com/news](https://www.phoronix.com/news/Linux-7.0-AWS-PostgreSQL-Drop)
- Points: 7
- Comments: 2

## Topic Body

- 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에도 동일한 영향이 미칠 가능성

## Comments



### Comment 54772

- Author: unstabler
- Created: 2026-04-06T18:25:15+09:00
- Points: 2

듣기로는 커널 개발자들이 약 10-20년 가까이 PostgreSQL 개발자들에게 '유저랜드에서의 스핀락은 권장하지 않으니 다시 생각해 주었으면 좋겠다' 라고 얘기했었다고 하네요..  
  
https://x.com/kosaki55tea/status/2040458791536497035

### Comment 54722

- Author: neo
- Created: 2026-04-06T09:50:05+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47644864) 
- Postgres 개발자인 Andres Freund의 [LKML 후속 글](https://lore.kernel.org/lkml/yr3inlzesdb45n6i6lpbimwr7b25kqk...)을 읽어볼 가치가 있음  
  - 성능 문제가 **재현 가능한 회귀(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 기사](https://lwn.net/Articles/994322/)에서 확인 가능함  

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

- PostgreSQL 18의 **비동기 I/O와 병렬 쿼리 최적화**가 이번 성능 저하를 상쇄할 수 있는지 궁금하다는 의견이 있었음  
  관련 내용은 [PostgreSQL 18 릴리스 노트](https://www.baremon.eu/postgresql-18-released-key-features-u...)에서 확인 가능함  

- PREEMPT_LAZY 같은 **동적 선점 모드**가 왜 필요한지 의문이라는 의견도 있었음  
  일반 사용자가 얻는 이점이 불분명하다는 것임  
  - 이에 대한 답글로, **대기 시간 증가 없이 처리량을 높이기 위한 설계**라는 설명이 있었음  
    커널이 더 명시적인 정보를 받아 **스케줄링 결정을 개선**할 수 있게 된다는 것임  

- FreeBSD 14와 15.0 사이에서 **10% 성능 저하**를 측정했는데, 이번 사례를 보니 위안이 된다는 댓글이 있었음  
  - “그래도 그만큼의 기능 추가는 있었냐”는 반응이 뒤따름  

- Phoronix가 **충분한 검증 없이 기사화했다**는 비판도 있었음  
  후속 메일에서는 벤치마크 자체가 잘못되었고, 실제로는 큰 문제가 아니라는 결론이 나왔음  
  - 다만 회귀는 **huge pages를 사용하지 않을 때만** 발생함  
    PostgreSQL에는 큰 문제가 없겠지만, huge pages를 쓸 수 없는 다른 앱에는 영향이 있을 수 있음  
    그래서 단순히 무시할 일은 아니라는 의견임  

- 오래된 [LKML 스레드 링크](https://lkml.org/lkml/2012/12/23/75)가 함께 공유되었음