필수사항
pgbench(공식 PostgreSQL 도구, TPC-B에 가까운 워크로드) 및 sysbench-tpcc(실제 트랜잭션 로드를 더 잘 나타내는 TPC-C 워크로드)는 둘 다 Aurabase 프로젝트의 표준 Postgres 16 연결 문자열에 대해 직접 실행되며 우회할 독점 API가 없습니다. 이 튜토리얼에서는 실제 주문과 GST 수치를 통해 합법적으로 증명할 수 있는 내용이 끝나는 부분을 보여줍니다.
단순함을 위한 pgbench, 현실감을 위한 sysbench-tpcc
pgbench는 PostgreSQL 자체와 함께 배포됩니다. 이미 Postgres 클라이언트 도구가 있는 경우 클라이언트에 별도로 설치할 필요가 없습니다. 기본 워크로드는 과거 TPC-B 벤치마크에 가까운 로드를 재현합니다. 즉, 간단하고 실행이 빠르며 첫 번째 신호에 유용합니다.
sysbench는 실제 OLTP 애플리케이션(주문, 결제, 재고)을 대표하는 트랜잭션의 혼합인 TPC-C 워크로드를 복제하는 sysbench-tpcc 플러그인을 사용하는 보다 일반적인 벤치마크 도구로, 일반 pgbench 워크로드보다 Aurabase 백엔드가 프로덕션에서 처리하는 작업에 더 가깝습니다.
연결 문자열을 검색하고 전용 테스트 기반을 만듭니다.
1
Aurabase 대시보드에서 연결 문자열을 검색합니다.
프로젝트의 데이터베이스 섹션, 표준 postgresql://user:password@host:5432/dbname형식.
2
생산 기반이 아닌 별도의 테스트 기반을 만드세요.
psql "$AURABASE_CONN" -c "CREATE DATABASE 벤치_테스트;"
pgbench 및 sysbench-tpcc는 테이블을 생성하고 채우고 수정합니다. 실제 트래픽을 제공하는 방식이 아닌 항상 전용 기반을 사용하십시오.
첫 실행 초기화 및 시작
1
데이터세트 초기화
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = 배율 인수(pgbench_accounts의 10 × 100,000개 행)
2
60초 실행, 10명의 클라이언트 경쟁
pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = 동시 클라이언트 · -j = 스레드 · -T = 지속 시간(초) · -P = 5초마다 보고
3
결과 읽기
pgbench는 연결 시간 유무에 관계없이 실행이 끝날 때 tps(초당 트랜잭션 수)를 표시합니다. 배율, 클라이언트 수, 실행당 기간을 확인하세요. 이 세 가지 매개 변수가 없으면 숫자만으로는 아무 의미가 없습니다.
보다 대표적인 트랜잭션 워크로드
1
sysbench 및 tpcc 플러그인 설치
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # 플러그인 컴파일을 위해 저장소의 README를 따르세요.
2
TPC-C 데이터 세트 준비
./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 준비
3
실행을 시작하세요
./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 실행
PostgreSQL 전용 sysbench-tpcc 튜닝 가이드는 2026년 5월 Percona에서 게시되었습니다. 이는 대표적인 실행을 실행하기 전에 shared_buffers 및 work_mem을 튜닝하는 데 유용합니다.
GST 수치만으로는 증명할 수 없는 것
tps는 배율, 동시 클라이언트 수, 기본 하드웨어 및 실행 시 활성화된 Postgres 설정에 따라 달라집니다. 서로 다른 매개변수로 얻은 두 시간 수치는 동일한 데이터베이스에서도 비교할 수 없습니다.
결과를 재현 가능한 참조로 사용하려면 Postgres 버전, 배율 인수, 클라이언트/스레드 수, 실행 기간 및 효과적인 postgresql.conf 구성을 체계적으로 문서화하십시오. 그림을 게시하기 전에 우리가 적용하는 프로토콜에 대해서는 전체 벤치마크 방법론을 참조하세요.
실행을 다시 시작하기 전에 Postgres 조정
A benchmark run often reveals a bottleneck before any adjustment — saturated connections, lagging autovacuum, missing index. Our Postgres tuning checklist in production and our article on max_connections sizing cover the settings to check before restarting a run.