PostgreSQL, 얼마나 느려질 수 있을까? 42,000배의 역설!

저자는 shared_buffers 설정을 조정하여 PostgreSQL의 성능을 저하시키는 실험을 진행했다. 초기 10GB에서 8MB로 설정했을 때, 버퍼 캐시(Buffer Cache) 크기가 줄어들면서 디스크 I/O가 증가하여 성능이 1/7로 감소했다. 추가적으로 2MB로 설정했을 때는 500 TPS 미만으로 떨어졌다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)를 약화시켜 디스크 접근 빈도를 높인 결과이다.

Autovacuum 설정을 통해 PostgreSQL의 성능을 저하시키는 방법도 제시되었다. autovacuum_vacuum_insert_threshold를 1로 설정하고, autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor를 0으로 설정하여 Autovacuum을 빈번하게 실행하도록 했다. 또한, maintenance_work_mem을 128kB로 설정하여 Autovacuum 작업의 메모리 사용량을 제한했다. 이러한 설정은 불필요한 작업을 증가시켜 성능 저하를 유발한다.

WAL 설정을 통해 성능을 저하시키는 방법도 제시되었다. wal_writer_flush_after를 0으로 설정하고, wal_writer_delay를 1로 설정하여 WAL 플러시(Flush)를 빈번하게 발생시켰다. 또한, min_wal_size와 max_wal_size를 32MB로 설정하고, checkpoint_timeout을 30초로 설정하여 체크포인트(Checkpoint)를 자주 발생시켰다. 이러한 설정은 디스크 I/O를 증가시켜 성능 저하를 유발한다.

저자는 random_page_cost와 cpu_index_tuple_cost 설정을 통해 인덱스 사용을 억제하여 성능을 저하시켰다. 두 설정을 1e300으로 설정함으로써, PostgreSQL이 인덱스 대신 테이블 스캔을 사용하도록 유도했다. 이는 무작위 페이지 접근 비용을 높여 인덱스 사용을 비효율적으로 만들고, 결과적으로 성능을 저하시키는 결과를 가져왔다.

PostgreSQL 18 버전부터 도입된 io_method와 io_workers 설정을 활용하여 I/O를 단일 스레드로 제한했다. io_method를 worker로 설정하고, io_workers를 1로 설정함으로써 모든 I/O 작업을 단일 스레드로 처리하도록 했다. 이로 인해 I/O 병목 현상이 발생하여 성능이 더욱 저하되었다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)의 또 다른 측면을 보여준다.