PostgreSQL용 AlloyDB에서 OLTP 성능 벤치마킹

이 문서에서는 PostgreSQL용 AlloyDB와 클라이언트 머신을 구성하여 OLTP 벤치마크 사양인 TPC-C를 사용하여 AlloyDB의 성능을 벤치마킹하는 방법을 설명합니다. 이 문서에서는 색인 삽입 전용 및 선택 전용과 같은 맞춤 읽기 및 쓰기 집약형 OLTP 시나리오를 실행하는 방법도 설명합니다.

이 문서의 안내는 AlloyDB 및 클라이언트 머신의 특정 구성을 기반으로 합니다. 벤치마킹 안내의 각 단계에 제공된 값을 사용합니다.

AlloyDB 워크로드 기능

AlloyDB는 모든 비즈니스와 중요한 워크로드에 적합한 엔터프라이즈급 안정성, 확장성, 성능을 제공합니다. AlloyDB는 트랜잭션 (OLTP), 분석 (OLAP), 하이브리드 (HTAP) 워크로드의 고성능을 지원하는 다음과 같은 구성요소와 기능을 제공합니다.

  • 로그 및 트랜잭션 관리
  • 동적 메모리 관리
  • 인공지능 및 머신러닝 통합
  • 내장 열 기반 엔진
  • 다층 캐시
  • 분산형 확장형 스토리지

관계형 데이터베이스 시스템에서는 일반적으로 데이터베이스 관리자가 벤치마킹을 위해 데이터베이스를 최적화해야 합니다. 여기에는 트랜잭션 로그 설정 구성, 올바른 버퍼 풀 크기 설정, 기타 데이터베이스 매개변수 또는 플래그 및 특성 수정이 포함됩니다. 이러한 설정은 인스턴스 크기 및 유형에 따라 다릅니다.

AlloyDB는 각 머신 유형에 최적화된 설정으로 사전 구성되어 제공됩니다. AlloyDB에서는 높은 OLTP 성능을 달성하기 위해 데이터베이스 수준에서 플래그를 조정할 필요가 없습니다. 대신 AlloyDB에는 높은 OLTP 성능이 내장되어 있습니다.

지원되는 벤치마크 유형

이 문서에서는 다음 도구를 사용하여 OLTP 벤치마크를 실행하는 방법을 보여줍니다.

OLTP 벤치마크 드라이버 사용 사례
HammerDB HammerDB는 분당 트랜잭션 수 (TPM)를 기준으로 시스템의 성능을 측정하고 자세한 통계 및 성능 측정항목이 포함된 보고서를 생성합니다.

HammerDB는 벤치마크 매개변수 맞춤설정을 지원하므로 데이터베이스 크기, 창고 수, 기타 워크로드 특성을 조정하여 다양한 시나리오를 시뮬레이션할 수 있습니다.

HammerDB에는 OLTP 시스템의 성능을 평가하기 위한 TPC-C 벤치마크 구현이 포함되어 있습니다. HammerDB TPC-C 구현을 사용하면 도매 공급업체 환경의 동작을 모방하는 트랜잭션을 혼합하여 TPC-C 벤치마크와 유사한 워크로드를 시뮬레이션할 수 있습니다.
pgbench pgbench는 PostgreSQL과 번들로 제공되는 벤치마킹 도구입니다. pgbench를 사용하면 데이터 삽입, 업데이트, 선택, 데이터베이스 시스템의 성능을 초당 트랜잭션 수 (TPS)로 측정하는 등의 트랜잭션 워크로드를 시뮬레이션할 수 있습니다.

pgbench를 사용하면 데이터베이스 크기, 클라이언트 수, 트랜잭션 조합을 맞춤설정하여 프로덕션 워크로드를 에뮬레이션하고 다양한 시나리오에서 시스템 동작에 대한 통계를 얻을 수 있습니다.
pgbench에는 TPC-B 구현이 포함되어 있습니다. pgbench TPC-B 구현은 TPC-B 벤치마크와 유사합니다.

시작하기 전에

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. PostgreSQL용 AlloyDB를 만들고 연결하는 데 필요한 Cloud API를 사용 설정합니다.

    API 사용 설정

    1. 프로젝트 확인 단계에서 다음을 클릭하여 변경할 프로젝트의 이름을 확인합니다.

    2. API 사용 설정 단계에서 사용 설정을 클릭하여 다음을 사용 설정합니다.

      • AlloyDB API
      • Compute Engine API
      • Cloud Resource Manager API
      • Service Networking API

      AlloyDB와 동일한 Google Cloud 프로젝트에 있는 VPC 네트워크를 사용하여 AlloyDB에 대한 네트워크 연결을 구성하려는 경우 Service Networking API가 필요합니다.

      다른 Google Cloud 프로젝트에 있는 VPC 네트워크를 사용하여 AlloyDB에 대한 네트워크 연결을 구성하려는 경우 Compute Engine API 및 Cloud Resource Manager API가 필요합니다.

데이터베이스 및 클라이언트 머신 설정 및 프로비저닝

AlloyDB 클러스터와 인스턴스를 만들어 벤치마크를 시작합니다. 달리 명시되지 않는 한 이 문서의 정보는 기본 AlloyDB 인스턴스로 128GB RAM이 있는 16개 vCPU를 기반으로 합니다.

AlloyDB 클러스터 및 인스턴스 만들기

  1. 클러스터 페이지로 이동합니다.

    클러스터로 이동

  2. 클러스터 만들기를 클릭합니다.

  3. 클러스터 ID 필드에 클러스터 이름을 입력합니다.

  4. 영역 가용성에서 클러스터 유형에 여러 영역 (고가용성)을 선택합니다.

  5. 기본 네트워크를 선택합니다.

  6. 데이터베이스 버전 필드에서 PostgreSQL 15를 선택합니다.

  7. 기본 영역의 위치와 비공개 IP 주소를 기록해 둡니다. 읽기 풀을 만들지 마세요.

  8. 클러스터 만들기를 클릭합니다.

클라이언트 머신 프로비저닝

OLTP 벤치마크를 실행하려면 적절한 처리 능력을 갖춘 클라이언트 머신이 필요합니다. HammerDB 및 pgbench와 같은 벤치마크 도구는 매우 병렬적으로 실행되며 많은 CPU를 사용합니다. OLTP 벤치마크를 실행할 때 클라이언트 머신이 병목 현상을 일으키면 안 됩니다.

달리 명시되지 않는 한 이 문서의 안내는 128GB 디스크가 있는 E2-standard-32 머신을 OLTP 벤치마크의 클라이언트로 사용하여 128GB RAM이 있는 16vCPU 머신에서 AlloyDB 인스턴스를 실행합니다. AlloyDB 기본 인스턴스와 동일한 영역에 클라이언트 머신을 만들어야 합니다.

가상 CPU 16개가 있는 AlloyDB 기본 인스턴스에서 TPC-C 벤치마크를 실행하려면 다음 단계에 따라 Compute Engine VM을 만들고 클라이언트 머신을 프로비저닝합니다.

  1. Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

    VM 인스턴스로 이동

  2. 연결하려는 AlloyDB 인스턴스가 포함된 프로젝트를 선택합니다.
  3. 인스턴스 만들기를 클릭합니다.
  4. 머신 구성 섹션을 클릭합니다.
  5. 인스턴스의 이름을 입력합니다.
  6. 인스턴스를 만들 영역을 구성합니다. 영역은 AlloyDB 기본 인스턴스의 영역과 동일해야 합니다.
  7. 머신 유형으로 e2-standard-32를 선택합니다.
  8. OS 및 저장용량 섹션의 기본값을 그대로 둡니다.
  9. 네트워킹 섹션을 클릭하고 네트워크 인터페이스를 AlloyDB에 대한 비공개 서비스 액세스에 구성된 VPC 네트워크로 설정합니다.
    네트워크 인터페이스가 비공개 서비스 액세스에 구성된 VPC 네트워크로 설정되어 있지 않으면 펼친 후 네트워크를 VPC 네트워크로 설정합니다.
  10. 관측 가능성 섹션의 기본값을 유지합니다.
  11. 보안 섹션을 클릭합니다.
  12. ID 및 API 액세스에서 액세스 범위를 모든 Cloud API에 대한 전체 액세스 허용으로 설정합니다.
  13. 고급 섹션의 기본값을 유지합니다.
  14. 만들기를 클릭합니다.
  15. VM이 생성된 후 SSH를 사용하여 만든 Compute Engine VM에 연결합니다.

벤치마크 드라이버 머신 설정

데이터베이스와 클라이언트 머신을 설치하고 설정한 후 Google Cloud에서 실행되는 클라이언트 머신을 구성합니다. 여기서 HammerDB 및 pgbench와 같은 벤치마킹 도구를 설치합니다.

벤치마크 드라이버 머신을 설정하려면 다음 단계를 따르세요.

  1. 다음 gcloud compute ssh 명령어를 사용하여 클라이언트 머신에 연결합니다.

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME"  --project "GOOGLE_PROJECT"

  2. PostgreSQL 클라이언트를 설치합니다.

    1. 다음 명령어를 사용하여 psql 애플리케이션이 포함된 PostgreSQL 클라이언트를 설치한 후 연결할 수 있는지 확인합니다.

      sudo apt-get update
sudo apt install postgresql-client

    2. 다음 명령어를 사용하여 클라이언트가 작동하고 AlloyDB에 연결할 수 있는지 확인합니다. 기본 AlloyDB 인스턴스의 비공개 IP 주소를 사용합니다.

      psql -h PRIVATE_IP -U postgres

  3. 다음 명령어를 실행하여 TPC-C 벤치마크용 HammerDB-4.6 드라이버를 설치합니다.

    mkdir hammerdb
pushd hammerdb
curl -OL https://github.com/TPC-Council/HammerDB/releases/download/v4.6/HammerDB-4.6-Linux.tar.gz
tar zxvf HammerDB-4.6-Linux.tar.gz

  4. 다음 명령어를 실행하여 TPC-B 및 기타 OLTP 벤치마킹을 위한 pgbench 드라이버를 설치합니다.

    sudo apt-get update
sudo apt-get install postgresql-contrib
pgbench --version

    pgbench --version가 오류 없이 실행되면 pgbench가 설치된 것입니다.

벤치마크 정리 수행

여러 벤치마크를 연속으로 실행하려는 경우 정확하고 안정적인 벤치마킹 결과를 얻으려면 각 벤치마크 간에 벤치마크 정리를 실행해야 합니다.

벤치마크 정리를 통해 이전 벤치마크의 잔여 효과가 새 벤치마크의 성능 측정에 영향을 미치지 않도록 할 수 있습니다. 벤치마크 정리 작업은 벤치마크 결과의 일관성과 반복성을 보장하는 데도 도움이 됩니다. 이는 여러 시스템 간에 의미 있는 비교를 수행하거나 하드웨어, 소프트웨어 또는 구성에서 최적화할 영역을 파악하는 데 필수적입니다.

다른 벤치마크를 실행하기 전에 벤치마크 정리를 실행하려면 다음 단계를 따르세요.

  1. 이전 벤치마크 데이터 또는 벤치마크 데이터베이스를 삭제합니다. 이전 벤치마크 데이터베이스를 삭제하려면 클라이언트 머신에서 다음 psql 명령어를 사용합니다.

    psql -h PRIVATE_IP -U postgres -c "DROP DATABASE IF EXISTS <database_name>;"

    psql 사용에 관한 자세한 내용은 데이터베이스 연결을 참고하세요.

  2. AlloyDB 인스턴스를 재부팅합니다. 이 단계에서는 데이터베이스 및 운영체제 수준에서 캐시를 삭제합니다.

TPC-C 벤치마크 실행

HammerDB는 OLTP 시스템의 성능을 평가하기 위한 TPC-C 벤치마크 구현이 포함된 벤치마킹 도구입니다. HammerDB의 TPC-C 구현을 사용하면 도매 공급업체 환경의 동작을 모방하는 트랜잭션을 혼합하여 TPC-C 벤치마크와 유사한 워크로드를 시뮬레이션할 수 있습니다.

HammerDB는 분당 트랜잭션 수 (TPM)를 기준으로 시스템의 성능을 측정하고 자세한 통계 및 성능 측정항목이 포함된 보고서를 생성합니다. 또한 HammerDB는 벤치마크 매개변수의 맞춤설정을 지원하므로 사용자가 데이터베이스 크기, 창고 수, 기타 워크로드 특성을 조정하여 다양한 시나리오를 시뮬레이션할 수 있습니다.

실적 평가 시나리오

TPC-C 벤치마킹의 성능은 다음 메서드를 사용하여 평가됩니다.

  • 부분적으로 (~30%) 캐시된 모드: 이 모드에서는 버퍼 캐시에 부분적으로만 들어갈 수 있는 대규모 TPC-C 데이터베이스가 생성됩니다. 이 모드의 트랜잭션은 항상 메모리에서 제공되지 않으며 기본 스토리지 하위 시스템에 I/O가 발생합니다. 이 시나리오는 많은 사용자의 OLTP 요구사항에 적용됩니다.

  • 전체 (100%) 캐시 모드: 이 모드에서는 TPC-C 데이터베이스가 버퍼 캐시에 완전히 들어갑니다. AlloyDB 인스턴스는 버퍼 캐시를 포함하여 사용 가능한 128GB RAM의 약 90% 를 사용합니다.

    이 모드에서는 읽기가 대부분 버퍼 캐시에서 제공되므로 TPC-C 트랜잭션이 최소한의 I/O를 실행하므로 부분적으로 캐시된 실행에 비해 TPM이 더 높을 것으로 예상됩니다. 이 시나리오는 I/O 요구사항이 매우 낮은 사용자의 OLTP 요구사항에 적용됩니다.

클라이언트 머신 설정

  1. 벤치마크 드라이버 머신을 설정합니다.

  2. 여러 벤치마크를 연속으로 실행하는 경우 벤치마크 정리를 실행합니다.

  3. 다음 명령어를 실행하여 hammerdb/HammerDB-4.6 directory를 엽니다.

    cd hammerdb/HammerDB-4.6

    이 디렉터리에서 명령어를 실행하여 클라이언트 머신을 설정합니다.

  4. 다음 명령어를 사용하여 setup.env 파일을 만듭니다.

    cat << EOF > setup.env
# Private IP of the AlloyDB primary instance
export PGHOST=PRIVATE_IP
# Postgres default port address. You do not need to change it unless you use non-default port address.
export PGPORT=5432   # default port to connect with postgres
# Number of TPC-C warehouses to load. This determines the overall database size.
export NUM_WAREHOUSE=576
# Number of users for running the benchmark.
export NUM_USERS=256
EOF

  5. 생성된 setup.env 파일을 수정하여 강조 표시된 모든 매개변수 값을 환경 설정에 가장 적합한 매개변수 값으로 바꿉니다.

  6. 선택사항: setup.env 파일에서 NUM_WAREHOUSE를 3200로 변경하여 부분적으로 (~30%) 캐시된 모드를 테스트합니다. 자세한 내용은 성능 평가 시나리오를 참고하세요.

  7. 선택사항: setup.env file에서 NUM_WAREHOUSE를 576로 변경하여 완전히 (100%) 캐시된 모드를 테스트합니다. 자세한 내용은 성능 평가 시나리오를 참고하세요.

데이터베이스에 TPC-C 데이터 로드

로드 단계는 성능 테스트를 실행하기 전에 벤치마크 데이터베이스를 초기 데이터로 채우는 프로세스를 말합니다.

로드 단계에서 데이터베이스는 TPC-C 사양에 따라 지정된 수의 창고, 고객, 기타 항목으로 채워집니다. 부하 단계의 목적은 성능 테스트를 위한 실제적인 워크로드를 만들고 여러 시스템에서 테스트 결과를 비교할 수 있도록 하는 것입니다.

로드 단계가 완료되면 데이터베이스는 정의된 초기 데이터 세트와 일관된 상태가 되어 TPC-C 벤치마크 테스트에 사용할 준비가 됩니다.

TPC-C 데이터베이스를 로드하려면 다음 단계를 따르세요.

  1. 다음 명령어를 사용하여 벤치마크 홈 디렉터리로 전환합니다.

    cd hammerdb/HammerDB-4.6

  2. 다음 콘텐츠를 복사한 후 build-tpcc.sh에 붙여넣습니다.

    #!/bin/bash -x

source ./setup.env

# create role tpcc with superuser login as 'postgres' and password as 'AlloyDB#123';
# -----------------------------------------------------

./hammerdbcli << EOF

# CONFIGURE PARAMETERS FOR TPCC BENCHMARK
# --------------------------------------
dbset db pg
dbset bm tpc-c

# CONFIGURE POSTGRES HOST AND PORT
# --------------------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC
# --------------------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user tpcc
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# SET NUMBER OF WAREHOUSES AND USERS TO MANAGE EACH WAREHOUSE
# THIS IMPORTANT METRIC ESTABLISHES THE DATABASE SCALE/SIZE
# --------------------------------------
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 10

# LOG OUTPUT AND CONFIGURATION DETAILS
# --------------------------------------
vuset logtotemp 1
print dict

# CREATE AND POPULATE DATABASE SCHEMA
# --------------------------------------
buildschema

waittocomplete
vudestroy
quit

EOF

  3. 다음 로드 명령어를 실행하고 명령어가 완료될 때까지 기다립니다.

    chmod +x ./build-tpcc.sh
mkdir results
sudo nohup ./build-tpcc.sh > results/build-tpcc.out 2>&1

  4. 로드 유효성을 검사합니다. 이전 스크립트가 완료되면 데이터베이스 로드가 성공적으로 완료되었는지 확인하는 것이 좋습니다. 데이터베이스 크기를 확인하려면 다음을 실행합니다.

    psql -h $PGHOST -p 5432 -U postgres
postgres=> \l+ tpcc
                                                                          List of databases
     Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size   | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+---------+------------+--------------------------------------------
 tpcc         | tpcc             | UTF8     | C.UTF-8 | C.UTF-8 |                                       | --- GB  | pg_default |
           |                  |          |         |         |                                       | 160.000 |            |
 (1 row)

30% 캐시된 TPC-C 구성 (창고 3,200개 포함)에서 tpcc 데이터베이스의 크기는 약 300GB입니다.

100% 캐시된 TPC-C 구성 (창고 576개 포함)에서는 tpcc 데이터베이스의 크기가 약 55GB가 됩니다.

TPC-C 벤치마크 실행

이제 TPC-C 성능 테스트를 실행할 준비가 되었습니다. TPC-C 벤치마크는 로드 단계에서 채워진 데이터베이스를 사용하여 실행됩니다. 벤치마크는 주문 입력, 결제 처리, 인벤토리 관리를 비롯한 일반적인 비즈니스 환경을 시뮬레이션하는 일련의 거래를 생성합니다. 워크로드는 분당 트랜잭션 수 (TPM)로 측정되며, 이는 시스템이 1분에 처리할 수 있는 전체 비즈니스 트랜잭션 수를 나타냅니다.

실행 단계는 실제적인 조건에서 데이터베이스 시스템에 스트레스를 가하고 여러 데이터베이스 시스템 간에 비교할 수 있는 성능 측정의 표준적인 방법을 제공하도록 설계되었습니다. 공급업체와 사용자는 종종 TPC-C 벤치마크의 결과를 사용하여 다양한 데이터베이스 시스템과 하드웨어 구성의 성능을 평가합니다.

TPC-C 벤치마크를 실행하려면 다음 단계를 따르세요.

  1. 벤치마크 홈 디렉터리로 전환합니다.

    cd hammerdb/HammerDB-4.6

  2. 다음 콘텐츠를 복사한 후 run-tpcc.sh에 붙여넣습니다.

    #!/bin/bash -x

source ./setup.env

./hammerdbcli << EOF
dbset db pg
dbset bm tpc-c

# CONFIGURE PG HOST and PORT
# -------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC DB
# -------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user postgres
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# BENCHMARKING PARAMETERS
# -------------------------
diset tpcc pg_driver timed
diset tpcc pg_rampup 10
diset tpcc pg_duration 60
diset tpcc pg_vacuum false
diset tpcc pg_partition false
diset tpcc pg_allwarehouse true
diset tpcc pg_timeprofile true
diset tpcc pg_connect_pool false
diset tpcc pg_dritasnap false
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 1

loadscript
print dict
vuset logtotemp 1
vuset vu $NUM_USERS
vucreate
vurun
waittocomplete
quit
EOF

  3. 다음 명령어를 사용하여 스크립트를 실행합니다.

    chmod +x run-tpcc.sh
mkdir results
sudo nohup ./run-tpcc.sh > results/run-tpcc.out 2>&1

  4. run-tpcc.sh 스크립트가 완료될 때까지 기다립니다. 이 스크립트는 완료하는 데 약 1시간 10분 정도 걸립니다. 스크립트가 완료되면 결과를 분석할 수 있습니다.

벤치마크 결과 분석

TPC-C 벤치마킹에서 분당 신규 주문 (NOPM) 및 분당 트랜잭션 수(TPM)는 데이터베이스 시스템의 성능을 측정하는 데 사용되는 성능 측정항목입니다.

  • NOPM: 시스템이 1분에 처리할 수 있는 신규 주문 거래 수를 측정합니다. 새 주문 거래는 TPC-C 벤치마크에서 가장 중요한 거래 중 하나이며 고객의 새 주문을 생성하는 작업과 관련이 있습니다.

  • TPM: 시스템이 1분에 처리할 수 있는 완료된 비즈니스 거래의 총수를 측정합니다. 거래에는 새 주문 거래와 TPC-C 벤치마크에 정의된 기타 유형의 거래(예: 결제, 배송, 주문 상태)가 포함됩니다.

    TPM은 실제 워크로드를 처리하는 시스템의 전반적인 기능을 측정할 수 있으므로 TPC-C 벤치마크의 주요 성능 측정항목입니다. NOPM은 전자상거래 또는 소매 시스템과 같이 새 주문 처리에 중점을 둔 시스템에 유용한 측정항목이 될 수 있습니다.

16vCPU 머신에서 30% 캐시된 TPC-C 데이터베이스를 사용하여 결과 보기

이 시나리오의 성능 수치를 추출하려면 다음 명령어를 사용합니다.

grep NOPM results/run-tpcc.out

예상되는 출력은 다음과 같습니다.

Vuser 1:TEST RESULT : System achieved 252970 NOPM from 582385 PostgreSQL TPM

16개 vCPU 머신 (NUM_WAREHOUSE=3200 및 NUM_USERS=256 사용)에서 30% 캐시된 TPC-C 데이터베이스를 사용하면 누적 582,385 AlloyDB TPM에서 252,970tpm-C (분당 신규 주문)가 관찰됩니다.

16vCPU 머신에서 100% 캐시된 TPC-C 데이터베이스로 결과 보기

16vCPU 머신 (NUM_WAREHOUSE=576 및 NUM_USERS=256 사용)의 100% 캐시된 TPC-C 데이터베이스에서 누적 974,264 AlloyDB TPM 중 428,316tpm-C (분당 신규 주문 수)가 관찰됩니다.

이 시나리오의 성능 수치를 추출하려면 다음 명령어를 사용합니다.

grep NOPM results/tpcc-run.out

예상되는 출력은 다음과 같습니다.

Vuser 1:TEST RESULT : System achieved 428316 NOPM from 974264 PostgreSQL TPM

vCPU 16개 머신의 성능 결과 요약

다음 표에는 16vCPU 머신의 벤치마크 성능 결과가 요약되어 있습니다.

TPC-C 시나리오 NUM_WAREHOUSE NUM_USERS NOPM 누적 TPM
캐시된 30% 3200 256 252,970 582,385
100% 캐시됨 576 256 428,316 974,264

데이터베이스 성능 측정항목 관찰

데이터베이스 시스템의 동작을 자세히 알아보려면 AlloyDB 모니터링 도구를 사용하여 CPU 사용량, 메모리 사용량, 초당 트랜잭션 수와 같은 중요한 시스템 측정항목을 관찰하세요. 자세한 내용은 인스턴스 성능 모니터링을 참고하세요.

예를 들어 이 벤치마크를 실행한 후 Google Cloud 콘솔의 AlloyDB 개요 페이지에서 100% 캐시된 TPC-C 실행의 평균 CPU 사용률이 거의 90%임을 확인할 수 있습니다.

64vCPU AlloyDB 인스턴스에서 TPC-C 벤치마크 실행

64vCPU AlloyDB 인스턴스에서 TPC-C 벤치마크를 실행하려면 TPC-C 벤치마크 실행과 동일한 설정 단계를 따르되 다른 머신 유형을 사용합니다.

AlloyDB 및 클라이언트 머신 설정

  1. 64 vCPU, 512GB를 머신 유형으로 대체하여 AlloyDB 클러스터 및 인스턴스를 만듭니다.

  2. n2-standard-64를 머신 유형으로 대체하여 클라이언트 머신을 프로비저닝합니다.

  3. 벤치마크 드라이버 머신을 설정합니다.

벤치마크 실행

  1. 여러 벤치마크를 연속으로 실행하는 경우 벤치마크 정리를 실행합니다.

  2. 다음 값을 대체하여 클라이언트 머신을 설정합니다.

    • PGHOST를 새 64vCPU AlloyDB 인스턴스의 비공개 IP로 설정합니다.
    • 캐시된 TPC-C 30% 시나리오의 경우 NUM_WAREHOUSE=12800 및 NUM_USERS=1024를 설정합니다.
    • 100% 캐시된 TPC-C 시나리오의 경우 NUM_WAREHOUSE=2304 및 NUM_USERS=1024를 설정합니다.

  3. TPC-C 데이터베이스 설정 및 로드 로드 속도를 높이려면 build-tpcc.sh에서 pg_num_vu 값을 64로 변경하고 diset tpcc pg_num_vu 64로 설정합니다.

  4. TPC-C 벤치마크를 실행합니다.

벤치마크 결과 분석

다음 표에는 64vCPU 머신의 벤치마크 성능 결과가 요약되어 있습니다.

벤치마크 모드 NUM_WAREHOUSE NUM_USERS NOPM 누적 TPM
캐시된 30% 12800 1024 589,598 1,371,160
100% 캐시됨 2304 1024 716,138 1,665,438

pgbench TPC-B 벤치마크 실행

TPC-B(Transaction Processing Performance Council Benchmark B)는 PostgreSQL용 벤치마킹 도구인 pgbench에서 사용할 수 있는 벤치마크 모드 중 하나입니다. TPC-B는 여러 창구 직원이 고객 계정에서 거래를 실행하는 은행 시나리오를 시뮬레이션합니다. 워크로드는 다음 유형의 거래로 구성됩니다.

  • 입금
  • 인출
  • 잔액 문의

벤치마크는 이러한 트랜잭션의 조합을 시뮬레이션하고 시스템이 처리할 수 있는 초당 트랜잭션 수를 측정하여 데이터베이스 시스템의 성능을 측정합니다.

pgbench의 TPC-B 모드는 합성 데이터베이스를 생성하고 TPC-B 워크로드와 유사한 트랜잭션 조합을 시뮬레이션하지만 TPC 조직에서 공식적으로 인증하지는 않습니다. 따라서 pgbench의 TPC-B 모드는 TPC-B 성능에 관한 유용한 근사치를 제공하지만 TPC-B 표준을 준수한다고 주장하는 데는 사용하지 마세요.

실적 측정 시나리오

이 섹션에서는 다음과 같은 중요한 모드에서 TPC-B 성능을 측정하는 방법을 설명합니다. 이러한 모드에서 다른 유일한 매개변수는 SCALE_FACTOR 매개변수의 값입니다.

부분적으로 캐시된 데이터베이스 시나리오

이 시나리오에서는 --scale= 50000를 사용하여 대용량 데이터베이스(크기 약 650GB)를 설정하고 초기화합니다. 메모리에 맞지 않고 상당한 디스크 I/O를 유발하는 대규모 데이터베이스를 사용하면 많은 프로덕션 워크로드를 사실적으로 나타낼 수 있습니다.

상당한 디스크 I/O를 유발하는 대규모 데이터베이스는 데이터베이스 설계 및 쿼리 최적화의 중요성을 강조할 수 있습니다. 대용량 데이터베이스는 느린 디스크 액세스 또는 비효율적인 쿼리와 같이 소규모 데이터베이스나 메모리에 완전히 상주하는 데이터베이스에서는 명확하지 않을 수 있는 디스크 I/O와 관련된 성능 문제를 노출할 수도 있습니다.

완전히 캐시된 데이터베이스 시나리오

이 시나리오에서는 --scale=4000를 사용하여 크기가 약 60GB인 데이터베이스를 설정하고 초기화하여 버퍼 풀에 있도록 합니다. 메모리 상주 데이터베이스를 벤치마킹하는 것은 제어된 환경에서 데이터베이스 시스템의 최대 성능을 평가할 수 있으므로 중요합니다.

메모리 상주 데이터베이스는 모든 데이터를 PostgreSQL 버퍼 풀에 저장하므로 디스크에서 데이터에 액세스할 때 발생할 수 있는 I/O 병목 현상을 제거합니다. 이 모드를 사용하면 디스크 I/O를 사용하는 데이터베이스를 벤치마킹할 때 명확하지 않을 수 있는 CPU 사용량 또는 잠금 문제와 같이 I/O와 관련 없는 성능 병목 현상을 식별하는 데 도움이 됩니다.

데이터베이스 서버 및 클라이언트 머신 설정

pgbench TPC-B 벤치마크를 실행하도록 인프라를 설정하려면 다음 단계를 따르세요.

  1. 16 vCPU, 128GB를 머신 유형으로 대체하여 AlloyDB 클러스터 및 인스턴스를 만듭니다.

  2. E2-standard-16 (minimum)를 머신 유형으로 대체하여 클라이언트 머신을 프로비저닝합니다.

  3. 벤치마크 드라이버 머신을 설정합니다.

  4. 벤치마크 정리 수행

pgbench TPC-B 벤치마크 실행

  1. 다음 Google Cloud CLI 명령어를 사용하여 클라이언트 머신에 연결합니다.

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. pgbench-setup.env 파일을 만듭니다.

    $ cat << EOF > pgbench-setup.env

# Private IP of the AlloyDB primary instance
export PGHOST=<private_ip>

# Set PGUSER to postgres as a default user.
export PGUSER=postgres

# Password set for PGUSER
export PGPASSWORD=<your pg password>

# In pgbench, the scale factor represents the size of the test database.
# and is defined as the number of 1 MB-sized data pages to be generated per client.
export SCALE_FACTOR=<scale_factor>

# Number of clients to drive the benchmark in throughput mode
export NUM_CLIENTS=<num_clients>

EOF

  3. 생성된 setup.env 파일을 수정하고 다음 매개변수 값을 환경 설정에 적합한 값으로 바꿉니다.

    • PRIVATE_IP: AlloyDB 인스턴스의 비공개 IP입니다.

    다음 표를 사용하여 <scale_factor> 및 <num_clients> 값을 선택합니다. 이러한 값은 머신 유형 및 데이터베이스 크기(전체 캐시 또는 부분 캐시)에 따라 확장되어야 합니다. 이 가이드의 예에서는 n2-highmem-16 머신 유형에 해당하는 SCALE_FACTOR 및 NUM_CLIENT 값을 사용합니다.

    완전히 캐시됨 부분적으로 캐시됨
    머신 유형 SCALE_FACTOR NUM_CLIENTS SCALE_FACTOR NUM_CLIENTS
    n2-highmem-2 500 48 6250 32
    n2-highmem-4 1000 96 12500 64
    n2-highmem-8 2000 192 25000 128
    n2-highmem-16 4000 384 50000 256
    n2-highmem-32 8000 768 100,000 512
    n2-highmem-64 16000 1536 200,000 1024

  4. pgbench 데이터베이스 만들기

    source ./pgbench-setup.env
psql -h $PGHOST -p 5432
postgres=> create database pgbench;
CREATE DATABASE

  5. 다음 명령어를 실행하여 pgbench 데이터베이스를 초기화하고 로드합니다. 이 단계를 통해 벤치마킹 데이터 세트가 생성되고 실제 데이터로 채워지므로 pgbench 데이터베이스에서 TPC-B 워크로드를 정확하게 시뮬레이션할 수 있습니다.

    source ./pgbench-setup.env
sudo nohup pgbench -i --host=$PGHOST --scale=$SCALE_FACTOR pgbench > /tmp/pgbench-tpcb-partially-cached-db-init.out 2>&1

    예상 로드 시간:

    • 부분적으로 캐시된 데이터베이스를 로드하는 데 약 6시간이 걸립니다.
    • 완전히 캐시된 데이터베이스를 로드하는 데 약 45분이 소요됩니다.

  6. 선택사항: /tmp/pgbench-tpcb-partially-cached-db-init.out 파일의 콘텐츠가 다음과 유사한지 확인하여 부하 정확성 검사를 실행합니다.

    generating data (client-side)...
100000 of 400000000 tuples (0%) done (elapsed 0.02 s, remaining 99.82 s)
.. .. ..
.. .. ..
399800000 of 400000000 tuples (99%) done (elapsed 534.60 s, remaining 0.27 s)
399900000 of 400000000 tuples (99%) done (elapsed 534.72 s, remaining 0.13 s)
400000000 of 400000000 tuples (100%) done (elapsed 534.85 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 1481.92 s (drop tables 0.01 s, create tables 0.04 s, client-side generate 540.93 s, vacuum 615.11 s, primary keys 325.84 s).

  7. 선택사항: 로드의 정확성을 추가로 확인하려면 모든 pgbench 테이블의 크기를 측정하는 다음 PostgreSQL 명령어를 실행합니다.

    1. pgbench 데이터베이스에 연결합니다.

      source ./pgbench-setup.env
psql -h $PGHOST -p 5432 -U postgres -d pgbench

    2. 다음 SQL 명령어를 실행합니다.

      pgbench=> SELECT nspname AS schema_name, relname AS table_name, pg_size_pretty(pg_total_relation_size(C.oid)) AS size FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema'
ORDER BY pg_total_relation_size(C.oid) DESC;

    3. 이전 명령어의 출력을 부분적으로 캐시된 데이터베이스 실행 (SCALE_FACTOR=50000)에서 얻은 출력과 비교합니다.

       schema_name |                table_name                 |  size
 -------------+-------------------------------------------+---------
 public      | pgbench_accounts                          | 731 GB
 public      | pgbench_accounts_pkey                     | 105 GB
 public      | pgbench_tellers                           | 32 MB
 public      | pgbench_tellers_pkey                      | 11 MB
 public      | pgbench_branches                          | 2952 kB
 public      | pgbench_branches_pkey                     | 1112 kB
 .. .. ..
 public      | pgbench_history                           | 0 bytes
 .. .. ..
 (29 rows)

  8. 다음 명령어를 실행하여 예금, 송금, 지불과 관련된 일련의 거래를 실행하여 금융 회계 시스템 워크로드를 시뮬레이션합니다. 이를 통해 과도한 워크로드에서 데이터베이스 성능을 측정할 수 있습니다.

    source ./pgbench-setup.env
mkdir -p ~/results/alloydb/pgbench
sudo nohup pgbench --host=$PGHOST --builtin=tpcb-like --time=3900 --jobs=$NUM_CLIENTS --client=$NUM_CLIENTS --scale=$SCALE_FACTOR --protocol=prepared --progress=1 pgbench > ~/results/alloydb/pgbench/pgbench.run.out 2>&1

벤치마크 결과 분석

~/results/alloydb/pgbench/pgbench.run.out 파일에서 이전 명령어의 출력을 확인합니다. TPS 숫자는 완전히 캐시된 데이터베이스 및 부분적으로 캐시된 데이터베이스 시나리오에 표시된 숫자와 근접해야 합니다.

완전히 캐시된 데이터베이스의 결과

pgbench TPC-B 벤치마크 실행의 마지막 명령어 출력은 다음과 비슷합니다. 여기서 --scale=4000는 다음과 같습니다.

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 4000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 84819501
latency average = 17.654 ms
latency stddev = 6.963 ms
tps = 21747.831164 (including connections establishing)
tps = 21750.579718 (excluding connections establishing)

데이터베이스 시스템의 동작을 자세히 알아보려면 Google Cloud 콘솔을 사용하여 CPU 사용량, 메모리 사용량, 초당 트랜잭션과 같은 시스템 측정항목을 모니터링할 수 있습니다. 자세한 내용은 인스턴스 모니터링을 참고하세요.

부분적으로 캐시된 데이터베이스의 결과

pgbench TPC-B 벤치마크 실행의 마지막 명령어 출력은 다음과 비슷합니다. 여기서 --scale=50000는 다음과 같습니다.

pgbench: warning: scale option ignored, using count from pgbench_branches table (50000)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>

scaling factor: 50000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 68073405
latency average = 21.992 ms
latency stddev = 29.272 ms
tps = 17453.913041 (including connections establishing)
tps = 17460.373303 (excluding connections establishing)

pgbench TPC-B 벤치마크의 성능 결과 요약

다음 표는 pgbench TPC-B 벤치마크의 성능 결과를 요약한 것입니다.

TPC-B 시나리오 SCALE_FACTOR TPS CPU 사용률 (%)
부분적으로 캐시됨 50000 17,460 96%
완전히 캐시됨 4000 21,750 94%

색인 삽입 전용 벤치마크 실행

색인 삽입 전용 벤치마크는 대부분의 OLTP 애플리케이션에서 AlloyDB의 성능 이점을 보여주기 위해 이 섹션에서 맞춤설정된 고도로 동시 실행되는 쓰기 집약적인 시나리오입니다. 이 벤치마크를 실행하려면 pgbench_history 테이블에 여러 색인을 만든 다음 여러 클라이언트 연결에서 pgbench_history 테이블에 INSERT 작업을 반복적으로 실행합니다.

색인 전용 삽입 벤치마크는 데이터베이스 테이블에 데이터를 삽입하는 성능을 측정하며 특히 색인이 쓰기 작업에 미치는 영향에 중점을 둡니다. 이 벤치마크를 사용하면 색인이 있는 테이블과 없는 테이블에 새 행을 추가하는 속도를 파악하여 삽입 중에 색인 유지관리로 인한 잠재적 속도 저하를 강조 표시할 수 있습니다.

AlloyDB는 PostgreSQL 쓰기 성능을 개선하여 OLTP 워크로드도 개선합니다. 쓰기 집약적인 OLTP 시나리오의 성능을 개선하기 위해 AlloyDB는 읽기에 도움이 되는 계층형 캐시 레이어와 쓰기에 사용되는 확장성이 뛰어난 분산 스토리지 엔진 기술을 비롯한 아키텍처 혁신을 제공합니다.

AlloyDB 및 클라이언트 머신 설정

색인만 삽입 벤치마크를 실행하도록 인프라를 설정하려면 다음 단계를 따르세요.

  1. 16 vCPU and 128 GB RAM를 머신 유형으로 대체하여 AlloyDB 클러스터 및 인스턴스를 만듭니다.

  2. E2-standard-16 (minimum)를 머신 유형으로 대체하여 클라이언트 머신을 프로비저닝합니다.

  3. 벤치마크 드라이버 머신을 설정합니다.

  4. 벤치마크 정리 수행

색인 삽입 전용 벤치마크 실행

  1. 다음 명령어 예를 사용하여 클라이언트 머신에 연결합니다.

    gcloud compute ssh --zone "<primary zone>" "<client machine name>" --project "<google-project>"

  2. 다음 명령어를 실행하여 환경을 설정합니다.

    export PGHOST=<private_ip>

  3. 다음 예를 사용하여 pgbench 데이터베이스를 만듭니다. 데이터베이스가 이미 있는 경우 데이터베이스를 삭제하고 다시 만듭니다.

    psql -h $PGHOST -p 5432 -U postgres -c "DROP DATABASE IF EXISTS pgbench"
psql -h $PGHOST -p 5432 -U postgres -c "CREATE DATABASE pgbench"

  4. pgbench 데이터베이스를 초기화하고 로드하여 벤치마킹 데이터 세트가 생성되고 실제 데이터로 채워지도록 합니다. 강조 표시된 매개변수를 수정한 후 다음 명령어를 실행합니다.

    sudo nohup pgbench -i  --host=$PGHOST --user=postgres --scale=25000 pgbench > /tmp/pgbench-index-insert-only-init.out 2>&1
...

postgres=> create database pgbench;
CREATE DATABASE pgbench

  5. 이전 명령어의 출력이 다음과 유사한지 확인합니다.

    dropping old tables...
creating tables...
generating data (client-side)...
100000 of 2500000000 tuples (0%) done (elapsed 0.03 s, remaining 636.43 s)
200000 of 2500000000 tuples (0%) done (elapsed 0.05 s, remaining 649.12 s)
.. .. ..
.. .. ..
2499900000 of 2500000000 tuples (99%) done (elapsed 3425.42 s, remaining 0.14 s)
2500000000 of 2500000000 tuples (100%) done (elapsed 3425.57 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 12851.19 s (drop tables 998.62 s, create tables 0.02 s, client-side generate 3460.33 s, vacuum 5299.93 s, primary keys 3092.29 s).

  6. 다음 명령어를 사용하여 index-init.sql 스크립트를 만듭니다.

    cat > index-init.sql << EOF
CREATE INDEX tid ON pgbench_history(tid);
CREATE INDEX bid ON pgbench_history(bid);
CREATE INDEX aid ON pgbench_history(aid);
CREATE INDEX delta ON pgbench_history(delta);
CREATE INDEX mtime ON pgbench_history(mtime);
EOF

  7. index-init.sql 스크립트를 실행합니다.

    psql -h $PGHOST -U postgres -d pgbench -f ./index-init.sql
Password for user postgres:
CREATE INDEX

  8. 선택사항: 데이터베이스 스키마 및 초기 로드의 유효성을 검사합니다.

    psql -h $PGHOST -U postgres -d pgbench

pgbench=> \dt
           List of relations
Schema |       Name       | Type  |  Owner
--------+------------------+-------+----------
 public | pgbench_accounts | table | postgres
 public | pgbench_branches | table | postgres
 public | pgbench_history  | table | postgres
 public | pgbench_tellers  | table | postgres
(4 rows)

pgbench=> \di
                       List of relations
 Schema |         Name          | Type  |  Owner   |      Table
--------+-----------------------+-------+----------+------------------
 public | aid                   | index | postgres | pgbench_history
 public | bid                   | index | postgres | pgbench_history
 public | delta                 | index | postgres | pgbench_history
 public | mtime                 | index | postgres | pgbench_history
 public | pgbench_accounts_pkey | index | postgres | pgbench_accounts
 public | pgbench_branches_pkey | index | postgres | pgbench_branches
 public | pgbench_tellers_pkey  | index | postgres | pgbench_tellers
 public | tid                   | index | postgres | pgbench_history
(8 rows)

    로드 후 데이터베이스 크기는 약 365GB가 될 것으로 예상됩니다.

    pgbench=> \l+ pgbench
                         List of databases
Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size  | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+--------+------------+--------------------------------------------
...
 pgbench      | postgres         | UTF8     | C.UTF-8 | C.UTF-8 |                                       | 365 GB | pg_default |
...

  9. 다음 명령어를 사용하여 index-inserts-only.sql 스크립트를 만듭니다.

    cat > index-inserts-only.sql << EOF
\set aid random(1, 1000000000)
\set bid random(1, 1000000000)
\set tid random(1, 1000000000)
\set delta random(-500000000, 500000000)
BEGIN;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
EOF

  10. 다음 명령어를 사용하여 pgbench 벤치마크를 실행합니다.

    sudo nohup pgbench --host=$PGHOST --user=postgres --time=3900 --client=256 --jobs=256 --scale=25000 --progress=1 --file=./index-inserts-only.sql pgbench > /tmp/pgbench-index-insert-only-run.out 2>&1

벤치마크 결과 분석

/tmp/pgbench-index-insert-only-run.out 파일에서 이전 명령어의 출력을 확인합니다. 이 벤치마크 테스트 중에 다음 출력 예와 같이 초당 약 52, 000개의 트랜잭션과 약 88% 의 CPU 사용률이 표시됩니다.

scaling factor: 25000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 201785196
latency average = 4.947 ms
latency stddev = 3.488 ms
tps = 51738.604613 (including connections establishing)
tps = 51742.459757 (excluding connections establishing)

64vCPU 인스턴스에서 Select Only 벤치마크 실행

pgbench는 지정된 데이터베이스에 대해 여러 클라이언트 연결에서 SELECT 쿼리를 반복적으로 실행하는 내장 선택 전용 시나리오를 지원합니다. 이 벤치마크는 INSERT, UPDATE, DELETE와 같은 데이터 수정 작업의 오버헤드를 도입하지 않고 데이터베이스의 읽기 성능을 측정하는 데 사용됩니다. 이러한 SELECT 쿼리는 색인 구조에서 직접 단일 데이터 행에만 액세스하므로 가장 빠르고 효율적인 유형의 선택 쿼리인 포인트 조회 쿼리입니다.

선택만 벤치마크를 실행하면 다음을 달성할 수 있습니다.

  • 최대 처리량 달성: 색인의 포인트 조회는 데이터베이스 시스템에서 가장 효율적인 쿼리 형식이므로 AlloyDB에서 달성할 수 있는 최대 처리량을 측정할 수 있습니다.

  • 확장성: 벤치마크만 선택하면 AlloyDB의 확장성을 2개 vCPU에서 AlloyDB에서 제공하는 최대 vCPU 구성까지 테스트할 수 있습니다.

AlloyDB 및 클라이언트 머신 설정

64 vCPU 머신 유형에서 AlloyDB 및 클라이언트 머신 설정

Select Only 벤치마크 실행

  1. 다음 명령어 예를 사용하여 클라이언트 머신에 연결합니다.

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. 다음 명령어를 사용하여 환경을 설정합니다.

    export PGHOST=<private_ip>

  3. 다음 예를 사용하여 pgbench 데이터베이스를 만듭니다.

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. pgbench 데이터베이스를 초기화합니다. 다음 명령어는 약 220GB의 실제 데이터로 pgbench 데이터베이스를 초기화합니다. 완전히 캐시된 선택만 벤치마크에는 --scale=15000를 사용합니다.

    다음 명령어를 실행합니다.

    sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=15000 pgbench > /tmp/pgbench-select-only-init.out 2>&1

  5. 이전 명령어의 출력이 다음과 유사한지 확인합니다.

    cat /tmp/pgbench-select-only-init.out
nohup: ignoring input
dropping old tables...
creating tables...
generating data (client-side)...
100000 of 1500000000 tuples (0%) done (elapsed 0.01 s, remaining 161.60 s)
200000 of 1500000000 tuples (0%) done (elapsed 0.03 s, remaining 224.35 s)
300000 of 1500000000 tuples (0%) done (elapsed 0.09 s, remaining 448.97 s)
.. .. ..
.. .. ..
1499900000 of 1500000000 tuples (99%) done (elapsed 1251.03 s, remaining 0.08 s)
1500000000 of 1500000000 tuples (100%) done (elapsed 1251.10 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 2204.62 s (drop tables 2.29 s, create tables 0.01 s, client-side generate 1271.82 s, vacuum 427.83 s, primary keys 502.66 s).

  6. pgbench를 실행합니다. 이 마지막 벤치마킹 단계는 완료하는 데 1시간 넘게 걸립니다.

    sudo nohup pgbench --host=$PGHOST --user=postgres  --builtin=select-only --time=3900 --jobs=256 --client=256 --scale=15000 --protocol=simple --progress=1 pgbench > /tmp/pgbench-select-only-run.out  2>&1

  7. 벤치마크가 완료되면 /tmp/pgbench-select-only-run.out 파일에서 최종 결과를 확인합니다.

벤치마크 결과 분석

이 벤치마크 테스트 중에 다음 출력 예와 같이 초당 약 467, 000개의 트랜잭션과 약 95% 의 CPU 사용률이 관찰됩니다.

cat /tmp/pgbench-select-only-run.out
transaction type: <builtin: select only>
scaling factor: 15000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 1823506174
latency average = 0.547 ms
latency stddev = 0.267 ms
tps = 467563.144333 (including connections establishing)
tps = 467583.398400 (excluding connections establishing)

AlloyDB 벤치마크 결과 요약

다음 표에는 이 문서에서 수행한 테스트를 기반으로 한 AlloyDB 벤치마크 결과가 요약되어 있습니다.

HammerDB TPC-C 실적 요약

AlloyDB 머신 유형 TPC-C 워크로드 시나리오 NUM_WAREHOUSE NUM_USERS 분당 신규 주문 수 (NOPM) 누적 TPM TPS로 변환됨
vCPU 16개 캐시된 30% 3200 256 252,970 582,385 9,706
vCPU 16개 100% 캐시됨 576 256 428,316 974,264 16,238
64vCPU 캐시된 30% 12800 1024 589,598 1,371,160 22,853
64vCPU 100% 캐시됨 2304 1024 716,138 1,665,438 27,757

pgbench 실적 요약

AlloyDB 머신 유형 pgbench 워크로드 시나리오 배율 계수 TPS CPU 비율
vCPU 16개 TPC-B 좋아요, 완전히 캐시됨 4000 20,359 96%
vCPU 16개 TPC-B 좋아요, 부분적으로 캐시됨 50000 14,060 94%
vCPU 16개 색인 삽입만 25000 51,742 88%
64vCPU 최대 처리량 (선택만 해당) 15000 467,583 95%

PostgreSQL용 Cloud SQL에서 OLTP 벤치마킹 실행

비교 분석을 위해 16vCPU 머신 유형의 PostgreSQL용 Cloud SQL에서 PostgreSQL의 상응하는 OLTP 성능을 테스트할 수 있습니다. 이 섹션에서는 이 가이드에서 OLTP 성능을 벤치마킹하는 데 사용되는 AlloyDB 설정과 비슷한 PostgreSQL용 Cloud SQL (또는 선택한 인프라에 배포된 PostgreSQL 서버)을 설정하는 방법을 설명합니다. 이 시나리오에서는 16vCPU SKU를 선택하고, 고가용성 (HA)을 사용 설정하고, 스토리지를 사용하여 사전 구성하는 작업이 포함됩니다.

시작하기 전에

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Install the Google Cloud CLI.

  5. To initialize the gcloud CLI, run the following command: 

    gcloud init

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Install the Google Cloud CLI.

  9. To initialize the gcloud CLI, run the following command: 

    gcloud init
  10. 사용자 계정에 Cloud SQL 관리자 및 Compute 뷰어 역할이 있는지 확인합니다.

    IAM 페이지로 이동

    역할 및 권한에 대해 자세히 알아보기

PostgreSQL용 Cloud SQL 인스턴스 프로비저닝

  1. PostgreSQL 인스턴스를 만들고 다음 값을 대체합니다.

    • 데이터베이스 버전: PostgreSQL 14
    • 시작할 구성 선택: 프로덕션
    • 리전 및 영역 가용성 선택: 리전으로 us-central1를 선택합니다.
    • 영역 가용성: 여러 영역 (가용성이 높음)
      • 기본 영역: us-central1-c
      • 보조 영역: us-central-1-f
    • 머신 유형: 메모리가 많은 16개 vCPU, 104GB 머신 이 머신은 PostgreSQL용 Cloud SQL에서 이 문서의 AlloyDB 벤치마킹 섹션에서 만든 일치하는 AlloyDB 인스턴스에 가장 근접한 머신입니다.
    • 스토리지 용량: 맞춤, 1,500GB
      • 저장용량 자동 증가 사용 설정
    • 암호화: Google-owned and Google-managed encryption key
    • 연결: 비공개 IP
      • 네트워크: default
      • 공개 IP: 사용 설정됨

  2. 인스턴스 만들기를 클릭합니다.

  3. PostgreSQL 인스턴스가 생성된 후 비공개 IP 주소를 기록해 둡니다. IP를 PGHOST로 사용하여 벤치마크와 연결을 설정합니다.

클라이언트 머신 프로비저닝

  1. PostgreSQL용 Cloud SQL 인스턴스를 프로비저닝합니다. 원하는 OLTP 벤치마크를 실행하려면 Cloud SQL의 기본 PostgreSQL용 Cloud SQL 인스턴스와 동일한 영역에 상당한 CPU 성능을 갖춘 클라이언트 머신이 필요합니다.

  2. 선택사항: 이전 단계 대신 다음이 참인 경우 AlloyDB 벤치마킹에 설정된 것과 동일한 클라이언트 머신을 사용할 수 있습니다.

    • 클라이언트 머신이 새 PostgreSQL(PostgreSQL용 Cloud SQL) 기본 인스턴스와 동일한 영역에 있습니다.
    • 클라이언트 머신이 최소 CPU, RAM, 디스크 크기 요구사항을 충족합니다.

    이 벤치마킹 가이드에서는 클라이언트 머신이 기본 인스턴스와 동일한 영역에 함께 배치되어 있고 서버를 최대 용량으로 가져올 만큼 충분히 클 때 클라이언트 머신을 재사용했습니다.

  3. 새 클라이언트 머신을 만든 경우 벤치마크 드라이버 머신을 설정합니다. 그렇지 않은 경우 실행하려는 벤치마크에 관한 이 가이드의 안내를 따르세요.

다음 단계