오늘은 PostgreSQL Benchmark의 약자로 보이는 pgbench에 대해 기록 남기겠습니다. 주제 선정에 고민이 많아 진도가 더뎠고 여러 개인적인 일정으로 바쁜 하루였지만, 기록의 가치를 위해 짧게나마 유익한 정보를 정리해 봅니다.
왜 하필 TPC-B 기반일까?
pgbench는 TPC-B라는 고전 벤치마크 규격을 모티브로 삼고 있습니다.
TPC(트랜잭션 성능 위원회)에서 만든 규격 중 TPC-C(OLTP)나 TPC-H(OLAP)는 여전히 현역이지만, TPC-B는 공식적으로 은퇴한 상태입니다. 그럼에도 pgbench가 이를 선택한 이유는 단순함에 있습니다.
정식 TPC 스펙은 구현이 매우 까다롭기로 유명합니다. pgbench는 이를 엄격하게 따르기보다 '느슨하게 구현'함으로써, 누구나 가볍고 빠르게 데이터베이스 성능을 측정할 수 있는 실용성을 택했습니다.
이렇게 따라하세요
초기화 단계 Initialization Phase
pgbench -i -s 1 -d your_db_name-s가 Scale Factor (SF)인데 데이터베이스 벤치마크 돌려보신 분은 익숙하겠지만, 데이터 크기를 결정하는 겂니다. SF값이 커지면 그 배수로 데이터가 커지는 겁니다. SF=1일때 초기화 직후 각 테이블에 아래와 같은 갯수의 로우가 있다고 합니다.
table # of rows
---------------------------------
pgbench_branches 1
pgbench_tellers 10
pgbench_accounts 100000
pgbench_history 0대략 테이블 이름으로 봐서 은행일을 시뮬레이션 해서 성능 평가 하는 것 같죠? 예전에 "트랜잭션" 이라고 하면 데이터베이스 교과서에서 은행 업무를 예제로 많이 들었어요. 아무래도 돈문제가 가장 중요한 트랜잭션 아니겠습니까? 여튼 그래서 TPC-B도 은행일을 기반으로 모델링 했나봅니다.
프로팁이 있다고 하여 키워드만 남겨요. 필요하면 더 찾아보세요. SF가 커질 때 더 빨리 초기화 하기 위해 "SET maintenance_work_mem = '2GB';" 같이 maintenance_work_mem 값을 기본보다 키우라는 말이고요.
두번째 팁은 initialization이 5단계로 구성되는데, 이걸 수동 조절가능하다고 하네요.
--init-steps=dtgvp: The standard steps: drop, "table create", generate, vacuum, primary keys.
라고 합니다. 아시겠죠?
성능 평가 단계 Benchmark Phase
데이터 준비가 끝났다면, 이제 실제 워크로드를 돌려볼 차례입니다. 기본적인 Read-Write(RW) 테스트와 Read-Only(RO) 테스트가 있다는 점을 기억해두면 좋습니다.
예시 A: 기본적인 TPC-B 유사 테스트 (Read-Write)
트랜잭션당 7단계(Update + Insert 포함)의 전체 과정을 테스트합니다.
pgbench -c 100 -j 8 -T 300 -P 5 -d your_db_name-c 100: 100개의 가상 데이터베이스 세션을 시뮬레이션합니다 (서버 측의 멀티 프로세스).-j 8: pgbench 툴 내에서 8개의 워커 스레드를 사용합니다 (클라이언트 측의 멀티 스레드).-T 300: 300초(5분) 동안 실행합니다.-P 5: 5초마다 진행 상황을 보고합니다 (성능이 갑자기 떨어지는 '딥' 현상을 포착하는 데 필수적이죠).
예시 B: 읽기 전용 테스트 (Select-Only = Read-Only)
주로 서버의 메모리나 캐싱 능력을 테스트할 때 자주 사용합니다.
pgbench -S -c 100 -j 8 -T 300 -P 10 -d your_db_name-S: 워크로드 중 SELECT 부분만 실행합니다.
한가지 더: 지연 시간(Latency) vs. 처리량(Throughput)
-
Closed-Loop (기본값): 클라이언트가 요청을 보내고, 결과를 기다린 '다음에' 다음 요청을 보냅니다. 고정된 수의 사용자가 얼마나 빨리 작업할 수 있는지를 측정하는 방식이죠.
-
Rate-Limited (
rate또는R):pgbench가 고정된 비율(예: 초당 500건의 트랜잭션)로 요청을 보냅니다. 만약 데이터베이스가 느려지면 "스케줄 지연(schedule lag)"이 발생하게 됩니다. 사용자들이 서로를 기다리지 않는 실제 환경의 트래픽을 시뮬레이션하기에 더 적합한 방식입니다.
Rate-limited를 좀 더 봐야 할 것 같은데, 경험적으로 다른 벤치마크 도우에서도 이런 방식은 그렇게 잘 동작하지 않고, 효과적으로 성능 특성을 포착하기 어려웠습니다. Closed-loop과 대비해서 말하면 진정한 의미로 open-loop 테스트를 하면 이상적인데 그게 현실의 워크로드가 유사할 테니까요. 대신 장비와 실험환경 구성의 용이성 문제, 재현성 등의 이슈가 얽혀 있습니다. 이 자체로도 흥미로운 주제이니 기회가 되면 한번 파보겠습니다.
너무 급하게 적어서 언제 다시 돌아와서 글을 수정해야 할 것 같은 기분입니다.
여튼 이정도 마무리하도록 하겠습니다.
