▲

Postgres를 느리게 만드는 방법

 (byteofdev.com)
3P by GN⁺ 17시간전 | ★ favorite | 댓글 1개
  • Postgres 성능을 극도로 저하시킬 수 있는 파라미터 조합에 대한 실험적 접근 소개
  • 일반적으로 캐시, 인덱스, WAL, I/O 등 다양한 요소를 역으로 튜닝함
  • shared_buffers, autovacuum, WAL 관련 옵션을 극단적으로 조작하여 TPS 42,000배 하락 달성
  • 새로운 Postgres 18/19 버전의 io_method 및 io_workers 등 최신 기능도 적용해 단일 I/O 스레드 제한 실험 수행
  • 실험 결과 Postgres 설정 파일만으로도 극단적 성능 저하가 가능함을 입증함

개요

이 글은 일반적으로 빠르게 만드는 데 집중하는 Postgres 튜닝과 반대로, 오로지 느리게 만드는 것을 목표로 하여 다양한 PostgreSQL 설정값만을 바꿔 성능을 한계까지 저하시킨 실험 내용임.
테스트는 BenchBase의 TPC-C 워크로드(128창고, 100커넥션, 각각 최대 10,000트랜잭션/초 시도, 최신 Postgres 19devel, Ryzen 7950x, 32GB RAM, 2TB SSD 환경, 120초 진행) 기반임.
기본값에서 성능은 7082 TPS였으며, 각 파라미터 조작을 통해 얼마나 느려지는지 단계별로 관찰함.

캐싱 대폭 줄이기

  • Postgres는 disk I/O를 줄이기 위해 강력한 캐시(shared_buffers) 를 활용함
  • 기본값(10GB)에서 shared_buffers를 8MB로 감소시, TPS가 1/7 수준(1052 TPS)으로 하락함
  • cache hit 비율이 99.90%에서 70.52%로 감소, read syscall 300배 이상 증가 현상 관측
  • 128kB까지 줄이려 시도했으나, Postgres는 최소 약 2MB까지만 허용하여 485 TPS로 추가 하락함

백그라운드 작업 증가(autovacuum 튜닝)

  • autovacuum 관련 모든 기준치를 최소화하여, 거의 매 작업마다 vacuum이 동작하게 만듦
    • autovacuum_vacuum_insert_threshold=1, autovacuum_naptime=1 등 조합
    • vacuum이 실질적 일이 없는 상태로도 거의 1초마다 반복 동작
  • 이 과정에서 maintenance_work_mem을 128kB로 축소, 모든 autovacuum 로깅 활성화
  • 이 결과, TPS가 293으로 감소(원래 대비 1/20 이하)
  • autovacuum 관련 실시간 로그를 통해 실제 빈번한 백그라운드 작업이 성능 저하의 원인임을 확인

WAL(Write-Ahead Log) 쓰기 작업 최악화

  • WAL 관련 파라미터를 전부 최악으로 조정
    • wal_writer_flush_after=0, wal_writer_delay=1, wal_sync_method=open_datasync 등
    • checkpoint를 30초마다 강제, min/max_wal_size=32MB로 최소한 유지
    • wal_level=logical, wal_log_hints=on 등 WAL에 불필요한 정보까지 기록
    • track_wal_io_timing, summarize_wal 등 추가 부하도 활성화
  • 이 결과 TPS는 98까지 감소(원래 대비 1/70 이하)
  • 로그에서 checkpoints가 몇백 ms마다 반복되는 등 비정상적 동작 확인

인덱스 효과 제거

  • 인덱스 사용이 모두 비용 최대로 계산되는 값(random_page_cost=1e300, cpu_index_tuple_cost=1e300)으로 설정, 실질적으로 인덱스 무효화
  • shared_buffers를 8MB까지 증액(안정성 확보용), TPS는 0.87까지 하락(7000배 느려짐 달성)

I/O 단일 스레드 강제

  • 최신 Postgres 18+ 기능 활용
  • io_method=worker, io_workers=1로 모든 I/O를 단일 워커 스레드로 강제
  • TPS가 0.016으로 추가 하락(42,000배 느려짐)
  • 100커넥션, 120초 실험에서 11트랜잭션만 성공할 정도로 제한적 성능

결론 및 재현 안내

  • 총 32가지 파라미터 조작만으로 운영 DB를 사실상 "마비"상태까지 만들 수 있음을 입증함
  • 오로지 postgresql.conf 설정만 건드려 성능 저하를 극대화할 수 있음
  • 실험 재현을 원하는 사용자는 BenchBase Postgres, 위 명시된 TPC-C 환경, 그리고 모든 설정 목록 참조
  • 일부 부가 파라미터나 추가적인 느리게 만들기 시도는 미포함

요약 파라미터 목록

  • shared_buffers = 8MB
  • autovacuum 관련 thresholds/scale_factor = 0~1 최저화
  • vacuum 관련 비용 및 메모리/로그: 최저&최대화
  • WAL 관련 sync/flush/로그/레벨 등: 느리게 유지
  • 인덱스 관련 random_page_cost, cpu_index_tuple_cost: 1e300 지정
  • io_method = worker, io_workers = 1
  • 기타 상세 값은 본문 목록 참조

마무리

  • 단순히 postgresql.conf 파일만으로 극심한 성능 저하를 유발할 수 있음
  • 실무에서는 해당 조합을 반대로(효율적 성능 개선)에 참고할 가치가 있음
  • 실험 진행 중 필자의 허리 통증으로 인한 중단 언급으로 글 마침
▲
GN⁺ 17시간전  [-]
Hacker News 의견
  • 인덱스, 여러 테이블, 트랜잭션, 엔티티 관계, 참조 무결성 같은 건 아예 잊어버리고 TRIRIGA의 초기 버전처럼 모든 데이터를 단일 테이블에서 KVS NoSQL SQL처럼 사용하는 방식 소개함
  • 이런 방식이 너무 재미있어서 계속 연재 시리즈 형태로 '일을 더 망치는 법'을 다루는 책도 나오면 좋겠다는 생각임, 배우면서 반대로 더 나은 방법을 찾을 수 있음, O’Reilly 스타일로 표지는 엉성하게 그린 판타지 동물(예: 머리가 양쪽에 달린 유니콘이 AirPods로 통화하면서 사기꾼에게 돈을 주고, 파워포인트를 만들며, 과식하고, 약물을 하는 모습 등)로 꾸미면 좋겠음
    • 2차 세계대전 때 실제로 이런 전략이 사용됐던 사례 있음, 조종사들의 생환을 위해 기상학자들이 가장 많은 인명 피해가 나는 조건을 먼저 찾은 다음 임무 설계를 그런 조건을 피해 계획함, 참고 링크 Suppose I wanted to kill a lot of pilots
    • 창작 글쓰기 수업에서도 연습 중 잘못 쓴 글을 읽고 분석하거나, 좋은 글을 일부러 나쁘게 다시 쓰는 연습이 있었는데, 그게 가장 도움되는 글쓰기 연습이었음
    • ORLYBooks 패러디 사이트도 참고 가능함
  • 관측 도구 실험을 위한 운영 환경 샌드박스가 있으면 정말 좋겠다는 생각임, 적당한 크기의 SaaS 스타일 시스템에 사용 시뮬레이션, 그리고 그냥 그럭저럭한 postgres/rabbit 구성으로 디버깅 도구나 전략의 실력을 점검해보고 싶음
  • 이 아이디어는 정말 천재적임, 최적화를 잘 하고 싶다면 처음이나 대조군으로 완전 반대로 망치기를 먼저 해보는 게 좋다고 생각함, 진짜로 데이터베이스나 시스템을 과학적으로 다루는지 아니면 막연하게 따라 하는 게 아닌지 자문해 볼 필요 있음
    • 클라우드 서비스 새로 쓸 때마다 나는 항상 그렇게 함, 먼저 Series A를 최대한 빨리 써보고 그 다음에 클라우드 비용 최적화 들어감
  • The Defence of Duffer's Drift라는 책이 이런 장르의 초창기 예시임, 첫 이야기에서는 분대 전술을 엉망으로 해서 대부분을 잃게 되고, 이후 이야기에선 전술적 조건을 바꿔가며 점점 결과가 나아지는 구조임, Musicians of Mars 2 같은 최신 전술 서적도 동일한 접근을 취함, 첫 Team Badger 이야기는 Duffer's Drift와 매우 비슷한데 위치, 장비, 기술에 따라 변화를 준 버전임, 관련 PDF는 The Defence of Duffer's Drift와 Musicians of Mars 2에서 볼 수 있음, Team Badger 지휘관이 참패한 뒤 자신감과 준비에 비해 왜 이렇게 처참히 패배했는지 되짚는 내용 인상적임
    • 비슷한 맥락의 영화로는 Groundhog Day와 특히 Edge of Tomorrow가 있음, 그리고 최근 영국 군사 블로그에 실린 현대 버전 오마주도 참고할 만함 Defence Baltic Bridge Dreams
  • 데드락 언급이 흥미로웠음, 트랜잭션 격리 수준 세팅을 조정하는 부분도 있을지 궁금함
  • B Sanderson 언급 반가웠음
  • Hyperbole and a Half와 db admin이 조합된 느낌임, 읽으면서 기분이 좋아졌고 몇 가지 배움도 있었음
  • 글쓰기 스타일과 생각을 풀어내는 방식이 정말 훌륭했음, 유쾌하게 읽을 수 있었음
답변달기