Linux 7.0, PostgreSQL 의 성능 저하 - 커널 프리엠션 모델 변경 이슈

AWS 엔지니어 Salvatore Dipietro가 Linux 7.0 개발 커널에서 PostgreSQL 처리량이 이전 커널 대비 절반(0.51x)으로 떨어진 다는것을 발견했다.

Graviton4 서버(96 vCPU)에서 pgbench 1,024 커넥션으로 벤치마킹? 했더니 아래와 같은 성능 이슈가 나왔다.

Linux 6.x: 정상 처리량
Linux 7.0: 50,751 TPS (절반 수준)
패치 적용 후: 98,565 TPS (복구)

해당 이슈는 단순한 버그가 아니라는 점이다. 커널 메인테이너들이 "이건 PostgreSQL이 고쳐야 할 문제"라고 이슈를 남겼다.

트러블슈팅: 어디서 문제가 발생했나

커널 프리엠션 모델 단순화

bisecting 으로 추적한 결과해보니 범인은 Intel 개발자 Peter Zijlstra의 커밋 7dadeaa6e851이었다. 이 커밋은 프리엠션 모델을 대대적으로 단순화했다.

기존 프리엠션 모델 (Linux 6.x)

PREEMPT\_NONE → 서버 워크로드 최적화 (자발적 프리엠션만)  
PREEMPT\_VOLUNTARY → 명시적 포인트에서만 스케줄링  
PREEMPT\_FULL → 항상 프리엠션 가능 (저지연)

Linux 7.0의 새 모델

PREEMPT\_LAZY → 스케줄러 제어 프리엠션  
PREEMPT\_FULL → 항상 프리엠션 가능

PREEMPT_NONE이 제거되면서 서버 워크로드 최적화 옵션이 사라졌다. arm64, x86_64, powerpc, riscv, s390, loongarch 등 요즘 많이들 사용하는 CPU 아키텍처 전부가 영향을 받는다.

PostgreSQL의 spinlock, 프리엠션에 당하다

PostgreSQL은 버퍼 관리자(buffer manager)에서 user-space spinlock을 광범위하게 사용한다.

// PostgreSQL spinlock 컨셉
void acquire_buffer_lock() {
    while (!try_lock(&buffer_spinlock)) {
        // busy-wait: CPU 계속 쓰면서 대기
        spin_pause();
    }
    // critical section
    release_lock(&buffer_spinlock);
}

spinlock은 락 보유 시간이 매우 짧다는 가정으로 설계되었지만 Linux 7.0 에서는 아래와 같이 이슈가 발생했다.

락 보유 중인 스레드가 프리엠션됨
다른 스레드들은 락 풀릴 때까지 busy-wait
CPU 사이클 낭비 → 처리량 반토막

해결책: 누가 고쳐야 하나?

시도 1: PREEMPT_NONE 복원 패치 (실패 가능성 99%)

AWS 엔지니어는 PREEMPT_NONE을 기본값으로 복원하는 패치를 메일링 리스트에 올렸다. 하지만 Peter Zijlstra의 답변 쉽지 않았다.

"The fix here is to make PostgreSQL make use of rseq slice extension"

번역하면 "PostgreSQL이 RSEQ 쓰면 됨 ㅇㅇ"이다. 커널은 안 고치겠다는 뜻이다.

시도 2: PostgreSQL이 RSEQ 도입 (일정 미정)

RSEQ (Restartable Sequences) 는 Linux 7.0에 함께 업스트림된 메커니즘이다. 약 10년간 개발됐다.

RSEQ 동작 방식

// RSEQ를 활용한 spinlock (개념적 예시)
void acquire_with_rseq() {
    // 1. RSEQ 타임슬라이스 확장 요청
    rseq->slice_ctrl.request = 1;
    barrier();

    // 2. Critical section (프리엠션 확률 낮아짐)
    while (!try_lock(&spinlock)) {
        spin_pause();
    }
    critical_section();
    unlock(&spinlock);

    barrier();
    // 3. 타임슬라이스 연장 받았으면 명시적으로 yield
    rseq->slice_ctrl.request = 0;
    if (rseq->slice_ctrl.granted)
        rseq_slice_yield();
}

락 보유 스레드가 CPU 타임슬라이스를 연장받아 프리엠션 당할 확률을 줄인다. 커널이 최대 5μs(마이크로초) 연장을 줄 수 있다.

문제는 뭐냐면

PostgreSQL에 RSEQ 구현 안 됨 - 일정 발표도 없음
OS 이식성 깨짐 - RSEQ는 Linux 전용이라 BSD, macOS 등에서 못 씀
수십 년 묵은 아키텍처 전면 수정 필요
이전 커널 호환성 유지해야 함 (RSEQ 없는 환경도 돌아야 함)

영향 범위

Ubuntu 26.04 LTS 사용자

2026년 4월 말 출시
Linux 7.0 탑재 확정
PostgreSQL 쓰면 자동으로 성능 반토막

자체 커널 관리 환경

자동 업그레이드 켜놨으면 끝
테스트 없이 프로덕션 배포했다간 새벽 온콜

ARM64 서버 (AWS Graviton, Ampere Altra)

가장 심각한 성능 저하 확인됨
x86_64는 케바케 (일부는 오히려 향상)

비용 임팩트 계산

현재 PostgreSQL 서버 10대로 운영 중이라면

기존: 10 서버 × $100/월 = $1,000/월
Linux 7.0 후: 20 서버 × $100/월 = $2,000/월
추가 비용: $1,000/월 (연간 $12,000)

EC2 m8g.24xlarge(96 vCPU) 기준으로 시간당 $4라면, 성능 유지하려면 2배 → 월 $2,880 추가 지출

관리형 DB(AWS RDS)는 AWS가 알아서 검증하고 배포를 늦출순 있지만 직업 운영하는 환경은 바로 영향을 받을 수 있다.

어떻게 하면 이슈를 방지할 수 있을까

단기 대응

1. 커널 업그레이드 봉인

# Ubuntu/Debian
sudo apt-mark hold linux-image-generic linux-headers-generic

# 현재 커널 확인
uname -r  # 6.x대면 일단 안전

# 업그레이드 대기 목록에서 제거
sudo apt-get remove --purge linux-image-7.0.0-*

2. 성능 베이스라인 측정

# pgbench 설치
sudo apt-get install postgresql-contrib

# 테스트 DB 생성
createdb pgbench_test

# 초기화 (스케일 팩터 100)
pgbench -i -s 100 pgbench_test

# 벤치마크 실행
pgbench -c 10 -j 2 -t 10000 pgbench_test

# 결과 기록해두기
# tps = 12345.67 (excluding connections establishing)

3. 락 경합 모니터링

-- PostgreSQL 락 대기 쿼리
SELECT 
    pid,
    usename,
    application_name,
    wait_event_type,
    wait_event,
    state,
    query_start,
    state_change,
    query
FROM pg_stat_activity
WHERE wait_event_type = 'Lock'
ORDER BY query_start;

-- Spinlock contention 간접 확인
SELECT 
    datname,
    numbackends,
    xact_commit,
    xact_rollback,
    blks_read,
    blks_hit
FROM pg_stat_database;

4. 커널 버전 명시적 관리

# Infrastructure as Code (Terraform 예시)
resource "aws_launch_template" "postgres_server" {
  name_prefix   = "postgres-"
  image_id      = "ami-xxxxx"  # Ubuntu 24.04 LTS (커널 6.8)
  instance_type = "m8g.2xlarge"

  user_data = base64encode(<<-EOF
    #!/bin/bash
    # 커널 업그레이드 차단
    apt-mark hold linux-image-generic
    apt-mark hold linux-headers-generic
  EOF
  )
}

중기 대응 (몇 개월)

PostgreSQL 커뮤니티 모니터링

# PostgreSQL 메일링 리스트 구독
# https://www.postgresql.org/list/

# GitHub 이슈 추적
# https://github.com/postgres/postgres/issues

RSEQ 지원 패치가 나오면

베타 버전 테스트 환경 구축
성능 회귀 테스트
프로덕션 롤아웃 계획

대체 방안 검토

# 성능 임팩트가 심각하면
alternatives = [
    "MySQL 8.0",           # spinlock 구현 다름
    "MariaDB",             # 동일
    "CockroachDB",         # 분산 아키텍처
    "PostgreSQL + 커널 6.x 고정"  # 가성비 국룰
]

장기 대응 (아키텍처)

멀티 버전 운영

# Kubernetes 환경 예시
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres-legacy
spec:
  template:
    spec:
      nodeSelector:
        kernel-version: "6.8"  # 안정 버전
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres-rseq
spec:
  template:
    spec:
      nodeSelector:
        kernel-version: "7.0"  # 테스트 용도

성능 회귀 테스트 자동화

#!/bin/bash
# kernel_regression_test.sh

KERNEL_OLD="6.8.0"
KERNEL_NEW="7.0.0"
THRESHOLD=0.9  # 90% 이하면 실패

# 기존 커널 벤치마크
boot_kernel $KERNEL_OLD
BASELINE=$(pgbench -c 10 -j 2 -t 10000 | grep tps | awk '{print $3}')

# 새 커널 벤치마크
boot_kernel $KERNEL_NEW
NEW_TPS=$(pgbench -c 10 -j 2 -t 10000 | grep tps | awk '{print $3}')

# 회귀 검사
RATIO=$(echo "$NEW_TPS / $BASELINE" | bc -l)
if (( $(echo "$RATIO < $THRESHOLD" | bc -l) )); then
    echo "성능 회귀 감지: $RATIO"
    exit 1
fi

기술적 논쟁: You broke it, you fix it

Linux 커뮤니티에서 뜨거운 감자가 됐다.

커널 개발자 입장

Peter Zijlstra:

"PostgreSQL의 spinlock 구현이 문제"
"RSEQ는 이미 제공함, 앱이 적응해야"
"커널 단순화는 장기적 이득"
"심각한 문제(seriously egregious things) 아니면 RSEQ로 해결됨"

사용자/DBA 입장

"You broke it, you fix it" (망가뜨린 쪽이 고쳐야 함)
PostgreSQL은 수백만 프로덕션 환경 가동 중
Linus도 심각한 성능 회귀는 breaking change라고 명시
RSEQ는 Linux 7.0에 새로 들어왔는데 어떻게 미리 대응함?

Linus Torvalds의 원칙

Linus는 과거 여러 번 명확히 했다:

"We don't break userspace"

50% 성능 저하는 명백한 breaking change다. 이전에도 유사한 회귀는 revert됐다.

커뮤니티 반응

"PostgreSQL이 1.5달 전 AMD Epyc Turin에서 Linux 7.0으로 성능 향상된 벤치마크가 있었음. arm64에서는 저하, x86에서는 향상이면 PostgreSQL이 둘 다 유지해야 하나?"

"kernel maintainer가 'seriously egregious things'라고 표현한 건 spinlock 쓰는 모든 앱을 무시하는 거 아닌가"

"RSEQ는 좋은데, 점진적으로 도입했어야지. API 먼저 몇 버전 제공하고, 그 다음에 PREEMPT_NONE 제거했어야."

왜 사전에 못 잡았나?

커널 테스트의 한계

현재 Linux 커널 CI/CD:

합성 벤치마크 (LMBench, UnixBench) ok
마이크로벤치마크 ok
실제 워크로드 (PostgreSQL, MySQL, MongoDB, Redis) 는 없었다.

PostgreSQL은 전세계에서 가장 많이 쓰이는 DB 중 하나인데, 이런 회귀를 릴리스 2주 전에 발견한 건 테스트 방법론의 문제다.

개선 방향

# 이상적인 커널 회귀 테스트 (개념적)
class KernelDatabaseTest(TestCase):
    DATABASES = ['postgresql', 'mysql', 'mongodb', 'redis']

    def test_throughput_regression(self):
        for db in self.DATABASES:
            baseline = self.benchmark(db, kernel='6.8')
            new = self.benchmark(db, kernel='7.0')

            ratio = new / baseline
            self.assertGreater(ratio, 0.9, 
                f"{db} 처리량 {ratio:.2f}x로 10% 이상 저하")

커널 메인테이너들도 이제 PostgreSQL을 "우선 지원 앱"으로 지정해야 한다는 의견이 나온다.

다른 DB는?

MySQL

아직 공식 보고 없음. 하지만 InnoDB도 spinlock 씀. 테스트 필요.

MongoDB

WiredTiger 스토리지 엔진도 유사한 구조. 확인 필요.

Redis

Single-threaded라 임팩트 작을 듯. 하지만 Redis Cluster는 다를 수 있음.

흥미로운 점

AMD Epyc Turin(x86_64)에서는 오히려 PostgreSQL 성능이 향상됐다는 벤치마크가 있다. 아키텍처별로 동기화 메커니즘이 다르기 때문이다.

타임라인

2026년 4월 4일: AWS 엔지니어 이슈 보고
2026년 4월 18일: Linux 7.0 stable 릴리스 예정
2026년 4월 말: Ubuntu 26.04 LTS 출시
미정: PostgreSQL RSEQ 지원 (일정 없음)

액션 아이템

DBA가 지금 해야 할 것

현재 커널 버전 확인 (uname -r)
자동 업그레이드 비활성화
성능 베이스라인 측정 및 기록
Ubuntu 26.04 업그레이드 계획 보류
모니터링 대시보드에 락 경합 메트릭 추가

개발자가 지금 해야 할 것

IaC에 커널 버전 명시
CI/CD에 성능 회귀 테스트 추가
PostgreSQL 메일링 리스트 모니터링
롤백 플랜 문서화

의사결정권자가 검토할 것

비용 영향 평가 (서버 2배 = 비용 2배)
업그레이드 일정 재조정
대체 DB 검토 (심각한 경우)
리스크 관리 계획 수립

결론

Linux 7.0의 PostgreSQL 성능 저하는 커널 현대화 vs 하위 호환성의 충돌이다.

커널 입장: 코드 단순화, 10년 개발한 RSEQ 제공함
PostgreSQL 입장: 수십 년 묵은 아키텍처, OS 이식성 깨짐
사용자 입장: 성능 반토막, 비용 2배, 억까

이 이슈가 시사하는 것:

인프라 의존성 명시적 관리 - 커널도 버전 고정해야
테스트 범위 확장 - 실제 워크로드 필수
점진적 마이그레이션 - API 먼저 제공, 강제 전환은 나중에
커뮤니케이션 - 주요 변경사항은 사전 공지

당분간은 프로덕션에서 Linux 7.0 업그레이드 연기가 정답이다. PostgreSQL RSEQ 지원이나 커널 revert 나올 때까지 기다리면서, 테스트 환경에서 철저히 검증하자.

대부분 내가 관리하는 서비스는 온프로미스라 업데이트만 안하면 되는거니 걱정은 덜하다.

참고 자료

Phoronix 기사: https://www.phoronix.com/news/Linux-7.0-AWS-PostgreSQL-Drop
RSEQ 커널 문서: https://docs.kernel.org/userspace-api/rseq.html
Lore 아카이브: https://lore.kernel.org/lkml/
EfficiOS 블로그: https://www.efficios.com/blog/2019/02/08/linux-restartable-sequences/

'실무 경험 > 기술 트렌드 & 리뷰' 카테고리의 다른 글

오픈소스의 문서가 부실한 이유와 방대한 이유 (0)	2025.04.29
CVE-2024-21626 runc 취약점 - 컨테이너 탈출 가능성과 대응 (0)	2024.02.29
번역: 모든 DB는 머지않아 벡터 데이터베이스가 될 것이다 (0)	2023.10.11
[번역] Laravel 은 지구상에서 가장 행복한 개발자 커뮤니티인가? (0)	2023.08.18

Logic in Code,Freedom in Travel.