# Postgres를 느리게 만드는 방법

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22213](https://news.hada.io/topic?id=22213)
- GeekNews Markdown: [https://news.hada.io/topic/22213.md](https://news.hada.io/topic/22213.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-07-28T17:33:14+09:00
- Updated: 2025-07-28T17:33:14+09:00
- Original source: [byteofdev.com](https://byteofdev.com/posts/making-postgres-slow/)
- Points: 9
- Comments: 2

## Summary

**Postgres**의 **성능 저하** 원인을 역으로 탐구하며, 데이터베이스의 주요 **설정 파라미터(예: shared_buffers, autovacuum, WAL 옵션, io_workers)** 만을 조작하여 실제 TPS를 **42,000배 이상 하락**시키는 실험을 진행합니다. **캐시 최소화, 불필요한 백그라운드 작업 증가, WAL 쓰기 악화, 인덱스 비활성화, I/O 단일 스레드 제한** 등의 조치만으로도, 대규모 시스템이 극단적으로 느려질 수 있음을 벤치마크로 입증합니다. 오로지 **postgresql.conf 파일의 세팅만으로 서비스 마비**를 유발할 수 있다는 점은 **파라미터 튜닝**의 중요성과 위험성을 동시에 보여줍니다. **DB 운영** 환경에서 효율적인 성능 관리를 위해, 설정값의 영향과 최적화 방법에 대한 개발자와 운영자의 주의를 강조하는 역설적인 방법의 글입니다.

## Topic Body

- **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 파일만으로 극심한 성능 저하를 유발할 수 있음
- 실무에서는 해당 조합을 반대로(효율적 성능 개선)에 참고할 가치가 있음
- 실험 진행 중 필자의 허리 통증으로 인한 중단 언급으로 글 마침

## Comments



### Comment 41888

- Author: neo
- Created: 2025-07-28T17:33:15+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=44704736) 
* 인덱스, 여러 테이블, 트랜잭션, 엔티티 관계, 참조 무결성 같은 건 아예 잊어버리고 TRIRIGA의 초기 버전처럼 모든 데이터를 단일 테이블에서 KVS NoSQL SQL처럼 사용하는 방식 소개함
* 이런 방식이 너무 재미있어서 계속 연재 시리즈 형태로 '일을 더 망치는 법'을 다루는 책도 나오면 좋겠다는 생각임, 배우면서 반대로 더 나은 방법을 찾을 수 있음, O’Reilly 스타일로 표지는 엉성하게 그린 판타지 동물(예: 머리가 양쪽에 달린 유니콘이 AirPods로 통화하면서 사기꾼에게 돈을 주고, 파워포인트를 만들며, 과식하고, 약물을 하는 모습 등)로 꾸미면 좋겠음
   * 2차 세계대전 때 실제로 이런 전략이 사용됐던 사례 있음, 조종사들의 생환을 위해 기상학자들이 가장 많은 인명 피해가 나는 조건을 먼저 찾은 다음 임무 설계를 그런 조건을 피해 계획함, 참고 링크 [Suppose I wanted to kill a lot of pilots](https://medium.com/butwhatfor/suppose-i-wanted-to-kill-a-lot...)
   * 창작 글쓰기 수업에서도 연습 중 잘못 쓴 글을 읽고 분석하거나, 좋은 글을 일부러 나쁘게 다시 쓰는 연습이 있었는데, 그게 가장 도움되는 글쓰기 연습이었음
   * [ORLYBooks 패러디 사이트](https://orlybooks.com/)도 참고 가능함
* 관측 도구 실험을 위한 운영 환경 샌드박스가 있으면 정말 좋겠다는 생각임, 적당한 크기의 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](https://www.armyupress.army.mil/Portals/7/combat-studies-institute/csi-books/swinton.pdf)와 [Musicians of Mars 2](https://api.army.mil/e2/c/downloads/2023/01/19/5a01ae1c/16-12-musicians-of-mars-ii-handbook-apr-16-public.pdf)에서 볼 수 있음, Team Badger 지휘관이 참패한 뒤 자신감과 준비에 비해 왜 이렇게 처참히 패배했는지 되짚는 내용 인상적임
   * 비슷한 맥락의 영화로는 Groundhog Day와 특히 Edge of Tomorrow가 있음, 그리고 최근 영국 군사 블로그에 실린 현대 버전 오마주도 참고할 만함 [Defence Baltic Bridge Dreams](https://wavellroom.com/2025/07/25/defence-baltic-bridge-dreams/)
* 데드락 언급이 흥미로웠음, 트랜잭션 격리 수준 세팅을 조정하는 부분도 있을지 궁금함
* B Sanderson 언급 반가웠음
* Hyperbole and a Half와 db admin이 조합된 느낌임, 읽으면서 기분이 좋아졌고 몇 가지 배움도 있었음
* 글쓰기 스타일과 생각을 풀어내는 방식이 정말 훌륭했음, 유쾌하게 읽을 수 있었음

### Comment 41912

- Author: sonic0987
- Created: 2025-07-29T11:17:02+09:00
- Points: 1
- Parent comment: 41888
- Depth: 1

훌륭하네요. 이런 접근 너무 좋아요