Dokumen ini menjelaskan cara mengonfigurasi AlloyDB untuk PostgreSQL dan mesin klien untuk mengukur performa AlloyDB menggunakan TPC-C, spesifikasi tolok ukur OLTP. Dokumen ini juga menjelaskan cara menjalankan skenario OLTP intensif baca dan tulis yang disesuaikan, seperti Index Insert Only dan Select Only.
Petunjuk dalam dokumen ini didasarkan pada konfigurasi AlloyDB dan mesin klien tertentu. Gunakan nilai yang diberikan untuk setiap langkah dalam petunjuk tolok ukur.
Kemampuan workload AlloyDB
AlloyDB memberikan keandalan, skalabilitas, dan performa tingkat perusahaan yang sesuai untuk semua bisnis dan workload penting. AlloyDB menyediakan komponen dan fitur berikut yang memungkinkan performa tinggi untuk workload transaksional (OLTP), analitis (OLAP), dan hybrid (HTAP):
- Pengelolaan log dan transaksi
- Pengelolaan memori dinamis
- Integrasi kecerdasan buatan dan machine learning
- Columnar engine bawaan
- Cache bertingkat
- Penyimpanan terdistribusi dan skalabel
Sistem database relasional biasanya memerlukan administrator database untuk mengoptimalkan database untuk tolok ukur, yang mencakup mengonfigurasi setelan log transaksi, menetapkan ukuran kumpulan buffer yang tepat, dan mengubah parameter atau flag dan karakteristik database lainnya. Setelan ini bervariasi, bergantung pada ukuran dan jenis instance.
AlloyDB telah dikonfigurasi sebelumnya dengan setelan yang dioptimalkan untuk setiap jenis mesin. AlloyDB tidak mengharuskan Anda menyesuaikan flag di tingkat database untuk mencapai performa OLTP yang tinggi; sebagai gantinya, AlloyDB memiliki performa OLTP tinggi bawaan.
Jenis tolok ukur yang didukung
Dokumen ini menunjukkan cara menjalankan tolok ukur OLTP menggunakan alat berikut:
Driver tolok ukur OLTP | Use cases |
---|---|
HammerDB | HammerDB mengukur performa sistem dalam hal transaksi
per menit (TPM) dan menghasilkan laporan yang mencakup
statistik dan metrik performa yang mendetail.
HammerDB mendukung penyesuaian parameter tolok ukur, yang memungkinkan Anda menyesuaikan ukuran database, jumlah gudang, dan karakteristik beban kerja lainnya untuk menyimulasikan berbagai skenario. HammerDB menyertakan penerapan tolok ukur TPC-C untuk mengevaluasi performa sistem OLTP. Implementasi TPC-C HammerDB memungkinkan Anda menyimulasikan beban kerja yang mirip dengan benchmark TPC-C, termasuk campuran transaksi yang meniru perilaku lingkungan pemasok grosir. |
pgbench | pgbench adalah alat tolok ukur yang disertakan dengan PostgreSQL.
pgbench memungkinkan Anda menyimulasikan beban kerja transaksi seperti memasukkan,
memperbarui, memilih data, dan mengukur performa sistem database dalam Transaksi Per Detik (TPS). Saat menggunakan pgbench, Anda dapat menyesuaikan ukuran database, jumlah klien, dan campuran transaksi untuk meniru beban kerja produksi dan mendapatkan insight tentang perilaku sistem dalam berbagai skenario. pgbench menyertakan implementasi TPC-B. Penerapan pgbench TPC-B mirip dengan tolok ukur TPC-B. |
Sebelum memulai
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verify that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verify that billing is enabled for your Google Cloud project.
-
Aktifkan Cloud API yang diperlukan untuk membuat dan menghubungkan ke AlloyDB untuk PostgreSQL.
Pada langkah Confirm project, klik Next untuk mengonfirmasi nama project yang akan Anda ubah.
Pada langkah Enable APIs, klik Enable untuk mengaktifkan berikut ini:
- AlloyDB API
- Compute Engine API
- Cloud Resource Manager API
- Service Networking API
Service Networking API diperlukan jika Anda berencana mengonfigurasi konektivitas jaringan ke AlloyDB menggunakan jaringan VPC yang berada di project yang sama Google Cloud dengan AlloyDB.
Compute Engine API dan Cloud Resource Manager API diperlukan jika Anda berencana mengonfigurasi konektivitas jaringan ke AlloyDB menggunakan jaringan VPC yang berada di project Google Cloud lain.
Buka halaman Cluster.
Klik Create Cluster.
Di kolom Cluster ID, masukkan nama untuk cluster Anda.
Di Ketersediaan zona, pilih Beberapa zona (Ketersediaan Tinggi) untuk jenis cluster.
Pilih jaringan default.
Di kolom Database version, pilih PostgreSQL 16.
Catat lokasi zona utama dan alamat IP pribadi. Jangan membuat kumpulan baca.
Klik Create Cluster.
Di konsol Google Cloud , buka halaman VM instances.
- Pilih project yang berisi instance AlloyDB yang ingin Anda hubungkan.
- Klik Create instance.
- Klik bagian Konfigurasi mesin.
- Masukkan Nama untuk instance.
- Konfigurasi zona tempat Anda ingin membuat instance. Zona harus sama dengan zona instance utama AlloyDB.
- Pilih jenis mesin e2-standard-32.
- Pertahankan nilai default di bagian OS and Storage.
- Klik bagian Networking, lalu tetapkan Network interfaces
ke jaringan VPC yang dikonfigurasi untuk akses layanan pribadi ke AlloyDB.
Jika Network interfaces tidak disetel ke jaringan VPC yang dikonfigurasi untuk akses layanan pribadi, perluas dan tetapkan Network ke jaringan VPC. - Pertahankan nilai default di bagian Observability.
- Klik bagian Keamanan.
- Di bagian Identitas dan akses API, tetapkan Cakupan akses ke Izinkan akses penuh ke semua Cloud API.
- Pertahankan nilai default di bagian Lanjutan.
- Klik Buat.
- Setelah VM dibuat, hubungkan ke VM Compute Engine yang Anda buat menggunakan SSH.
Hubungkan ke mesin klien menggunakan perintah
gcloud compute ssh
berikut:gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"
Instal klien PostgreSQL.
Gunakan perintah berikut untuk menginstal klien PostgreSQL yang menyertakan aplikasi psql, lalu pastikan Anda dapat terhubung.
sudo apt-get update sudo apt install postgresql-client
Gunakan perintah berikut untuk memastikan klien berfungsi dan Anda dapat terhubung ke AlloyDB. Gunakan alamat IP pribadi instance AlloyDB utama Anda.
psql -h PRIVATE_IP -U postgres
Instal driver HammerDB-4.6 untuk tolok ukur TPC-C dengan menjalankan perintah berikut:
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
Instal driver pgbench untuk TPC-B dan tolok ukur OLTP lainnya dengan menjalankan perintah berikut:
sudo apt-get update sudo apt-get install postgresql-contrib pgbench --version
Jika
pgbench --version
berjalan tanpa error, berarti pgbench telah diinstal.Hapus data tolok ukur atau database tolok ukur sebelumnya. Untuk menghapus database tolok ukur sebelumnya, gunakan perintah
psql
berikut dari mesin klien:psql -h PRIVATE_IP -U postgres -c "DROP DATABASE IF EXISTS <database_name>;"
Untuk mengetahui informasi selengkapnya tentang penggunaan
psql
, lihat Menghubungkan ke database.Mulai ulang instance AlloyDB. Langkah ini menghapus cache di tingkat database dan sistem operasi.
Mode di-cache sebagian (~30%): Dalam mode ini, database TPC-C besar dibuat, yang hanya dapat masuk sebagian ke dalam cache buffer. Transaksi dalam mode ini tidak selalu ditayangkan dari memori dan menimbulkan I/O ke subsistem penyimpanan yang mendasarinya. Skenario ini berlaku untuk kebutuhan OLTP banyak pengguna.
Mode yang di-cache sepenuhnya (100%): Dalam mode ini, database TPC-C sepenuhnya sesuai dalam cache buffer. Instance AlloyDB menggunakan sekitar 90% RAM 128 GB yang tersedia, termasuk cache buffer.
Karena transaksi TPC-C melakukan I/O minimal —karena sebagian besar pembacaan ditayangkan dari cache buffer— dalam mode ini, TPM yang lebih tinggi diharapkan dibandingkan dengan proses yang di-cache sebagian. Skenario ini berlaku untuk kebutuhan OLTP pengguna dengan kebutuhan I/O yang sangat rendah.
Jika Anda menjalankan beberapa benchmark secara berurutan, lakukan pembersihan benchmark.
Buka
hammerdb/HammerDB-4.6 directory
dengan menjalankan perintah berikut:cd hammerdb/HammerDB-4.6
Anda menjalankan perintah dari direktori ini untuk menyiapkan mesin klien.
Buat file
setup.env
menggunakan perintah berikut: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
Edit file
setup.env
yang dihasilkan dengan mengganti semua parameter value yang ditandai dengan parameter value yang paling sesuai untuk penyiapan lingkungan Anda.Opsional: Uji mode yang di-cache sebagian (~30%) dengan mengubah
NUM_WAREHOUSE
menjadi3200
di filesetup.env
. Untuk mengetahui informasi selengkapnya, lihat Skenario evaluasi performa.Opsional: Uji mode yang di-cache sepenuhnya (100%) dengan mengubah
NUM_WAREHOUSE
menjadi576
disetup.env file
. Untuk mengetahui informasi selengkapnya, lihat Skenario evaluasi performa.Beralih ke direktori beranda tolok ukur menggunakan perintah berikut:
cd hammerdb/HammerDB-4.6
Salin konten berikut, lalu tempel ke
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
Jalankan perintah muat berikut dan tunggu hingga perintah selesai.
chmod +x ./build-tpcc.sh mkdir results sudo nohup ./build-tpcc.sh > results/build-tpcc.out 2>&1
Validasi beban. Setelah skrip sebelumnya selesai, sebaiknya Anda mengonfirmasi bahwa pemuatan database berhasil. Untuk memverifikasi ukuran database, jalankan perintah berikut:
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)
Beralih ke direktori utama benchmark:
cd hammerdb/HammerDB-4.6
Salin konten berikut, lalu tempel ke
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
Jalankan skrip menggunakan perintah berikut:
chmod +x run-tpcc.sh mkdir results sudo nohup ./run-tpcc.sh > results/run-tpcc.out 2>&1
Tunggu hingga skrip
run-tpcc.sh
selesai. Skrip memerlukan waktu sekitar 1 jam 10 menit untuk selesai. Setelah skrip selesai, Anda dapat menganalisis hasilnya.NOPM: mengukur jumlah transaksi pesanan baru yang dapat ditangani sistem dalam satu menit. Transaksi pesanan baru adalah salah satu transaksi terpenting dalam tolok ukur TPC-C dan melibatkan pembuatan pesanan baru untuk pelanggan.
TPM: mengukur jumlah total transaksi bisnis yang diselesaikan yang dapat ditangani sistem dalam satu menit. Transaksi mencakup transaksi pesanan baru serta jenis transaksi lainnya yang ditentukan dalam tolok ukur TPC-C, seperti pembayaran, pengiriman, dan status pesanan.
TPM adalah metrik performa utama untuk benchmark TPC-C karena memberikan ukuran keseluruhan kemampuan sistem untuk menangani beban kerja yang realistis. NOPM dapat menjadi metrik yang berguna untuk sistem yang berfokus pada pemrosesan pesanan baru, seperti sistem e-commerce atau retail.
Buat cluster dan instance AlloyDB, dengan mengganti
64 vCPU, 512GB
sebagai jenis mesin.Sediakan mesin klien, dengan mengganti
n2-standard-64
sebagai jenis mesin.Jika Anda menjalankan beberapa benchmark secara berurutan, lakukan pembersihan benchmark.
Siapkan mesin klien, dengan mengganti nilai berikut:
- Tetapkan
PGHOST
ke IP Pribadi instance AlloyDB 64 vCPU baru Anda. - Untuk skenario TPC-C yang di-Cache 30%, tetapkan
NUM_WAREHOUSE=12800
danNUM_USERS=1024
. - Untuk skenario TPC-C yang 100% di-Cache, tetapkan
NUM_WAREHOUSE=2304
danNUM_USERS=1024
.
- Tetapkan
Siapkan dan muat database TPC-C. Untuk mempercepat pemuatan, ubah nilai
pg_num_vu
menjadi 64 dibuild-tpcc.sh
sebagaidiset tpcc pg_num_vu 64
.- Deposit
- Penarikan
- Pengecekan saldo
Buat cluster dan instance AlloyDB, dengan mengganti
16 vCPU, 128GB
sebagai jenis mesin.Sediakan mesin klien, dengan mengganti
E2-standard-16 (minimum)
sebagai jenis mesin.Hubungkan ke mesin klien menggunakan perintah Google Cloud CLI berikut:
gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"
Buat file
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
Edit file
setup.env
yang dihasilkan dan ganti nilai parameter berikut dengan nilai yang sesuai untuk penyiapan lingkungan Anda.- PRIVATE_IP: IP pribadi instance AlloyDB Anda.
Gunakan tabel berikut untuk memilih nilai
<scale_factor>
dan<num_clients>
. Nilai ini harus diskalakan dengan jenis mesin dan ukuran database (di-cache sepenuhnya atau sebagian). Contoh dalam panduan ini menggunakan nilaiSCALE_FACTOR
danNUM_CLIENT
yang sesuai dengan jenis mesinn2-highmem-16
.Di-Cache Sepenuhnya Di-Cache Sebagian Machine Type 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 100000 512 n2-highmem-64 16000 1536 200000 1024 Membuat database
pgbench
.source ./pgbench-setup.env psql -h $PGHOST -p 5432 postgres=> create database pgbench; CREATE DATABASE
Lakukan inisialisasi dan muat database pgbench dengan menjalankan perintah berikut. Langkah ini memastikan bahwa set data benchmarking dibuat dan diisi dengan data realistis, yang memungkinkan Anda mensimulasikan beban kerja TPC-B secara akurat pada database pgbench.
source ./pgbench-setup.env sudo nohup pgbench -i --host=$PGHOST --scale=$SCALE_FACTOR pgbench > /tmp/pgbench-tpcb-partially-cached-db-init.out 2>&1
Perkiraan waktu pemuatan:
- Database yang di-cache sebagian memerlukan waktu sekitar 6 jam untuk dimuat.
- Database yang di-cache sepenuhnya memerlukan waktu sekitar 45 menit untuk dimuat.
Opsional: Lakukan pemeriksaan akurasi pemuatan dengan memastikan bahwa isi file
/tmp/pgbench-tpcb-partially-cached-db-init.out
serupa dengan berikut ini: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).
Opsional: Untuk memvalidasi lebih lanjut akurasi beban, jalankan perintah PostgreSQL berikut yang mengukur ukuran semua tabel pgbench:
Hubungkan ke database pgbench:
source ./pgbench-setup.env psql -h $PGHOST -p 5432 -U postgres -d pgbench
Jalankan perintah SQL berikut:
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;
Bandingkan output perintah sebelumnya dengan output yang Anda peroleh untuk menjalankan database yang di-cache sebagian (
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)
Jalankan perintah berikut untuk menyimulasikan beban kerja sistem akuntansi keuangan dengan menjalankan serangkaian transaksi yang melibatkan penyetoran, transfer, dan pembayaran, yang memungkinkan Anda mengukur performa database di bawah beban kerja yang berat.
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
Buat cluster dan instance AlloyDB, dengan mengganti
16 vCPU and 128 GB RAM
sebagai jenis mesin.Sediakan mesin klien, dengan mengganti
E2-standard-16 (minimum)
sebagai jenis mesin.Hubungkan ke komputer klien menggunakan contoh perintah berikut:
gcloud compute ssh --zone "<primary zone>" "<client machine name>" --project "<google-project>"
Siapkan lingkungan dengan menjalankan perintah berikut:
export PGHOST=<private_ip>
Buat database
pgbench
menggunakan contoh berikut. Jika database sudah ada, hapus database tersebut dan buat ulang.psql -h $PGHOST -p 5432 -U postgres -c "DROP DATABASE IF EXISTS pgbench" psql -h $PGHOST -p 5432 -U postgres -c "CREATE DATABASE pgbench"
Lakukan inisialisasi dan muat database pgbench untuk memastikan set data benchmarking dibuat dan diisi dengan data yang realistis. Edit parameter yang ditandai lalu jalankan perintah berikut:
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
Pastikan output perintah sebelumnya mirip dengan berikut ini:
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).
Buat skrip
index-init.sql
menggunakan perintah berikut: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
Jalankan skrip
index-init.sql
:psql -h $PGHOST -U postgres -d pgbench -f ./index-init.sql Password for user postgres: CREATE INDEX
Opsional: Validasi skema database dan pemuatan awal:
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)
Setelah pemuatan, ukuran database diperkirakan sekitar 365 GB:
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 | ...
Buat skrip
index-inserts-only.sql
menggunakan perintah berikut: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
Jalankan tolok ukur pgbench menggunakan perintah berikut:
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
Mencapai throughput maksimum: Karena pencarian titik pada indeks adalah bentuk kueri yang paling efisien dalam sistem database, Anda dapat mengukur throughput maksimum yang dapat dicapai AlloyDB.
Skalabilitas: Hanya tolok ukur yang dipilih membantu Anda menguji skalabilitas AlloyDB dari 2 vCPU hingga konfigurasi vCPU maksimum yang ditawarkan oleh AlloyDB.
Hubungkan ke komputer klien menggunakan contoh perintah berikut:
gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"
Siapkan lingkungan menggunakan perintah berikut:
export PGHOST=<private_ip>
Buat database pgbench menggunakan contoh berikut:
psql -h $PGHOST -p 5432 -U postgres postgres=> create database pgbench; CREATE DATABASE
Lakukan inisialisasi database pgbench. Perintah berikut menginisialisasi database pgbench dengan sekitar 220 GB data realistis. Anda menggunakan
--scale=15000
untuk tolok ukur Hanya Pilih yang di-cache sepenuhnya.Jalankan perintah berikut:
sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=15000 pgbench > /tmp/pgbench-select-only-init.out 2>&1
Pastikan output perintah sebelumnya mirip dengan berikut ini:
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).
Jalankan pgbench. Langkah benchmarking terakhir ini memerlukan waktu lebih dari satu jam untuk diselesaikan.
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
Setelah benchmark selesai, periksa file
/tmp/pgbench-select-only-run.out
untuk melihat hasil akhir.- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verify that billing is enabled for your Google Cloud project.
-
Install the Google Cloud CLI.
-
Jika Anda menggunakan penyedia identitas (IdP) eksternal, Anda harus login ke gcloud CLI dengan identitas gabungan Anda terlebih dahulu.
-
Untuk melakukan inisialisasi gcloud CLI, jalankan perintah berikut:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verify that billing is enabled for your Google Cloud project.
-
Install the Google Cloud CLI.
-
Jika Anda menggunakan penyedia identitas (IdP) eksternal, Anda harus login ke gcloud CLI dengan identitas gabungan Anda terlebih dahulu.
-
Untuk melakukan inisialisasi gcloud CLI, jalankan perintah berikut:
gcloud init
-
Pastikan Anda memiliki peran Admin Cloud SQL dan Compute Viewer di
akun pengguna.
Pelajari lebih lanjut tentang peran dan perizinan
Buat instance PostgreSQL, dengan mengganti nilai berikut:
- Versi database: PostgreSQL 14
- Pilih konfigurasi untuk memulai: Produksi
- Pilih region dan ketersediaan zona: Pilih
us-central1
sebagai region. - Ketersediaan zona: Beberapa zona (Ketersediaan Tinggi)
- Zona utama:
us-central1-c
- Zona sekunder:
us-central-1-f
- Zona utama:
- Jenis mesin: Mesin Memori Tinggi 16 vCPU, 104 GB. Ini adalah mesin terdekat yang ditawarkan Cloud SQL untuk PostgreSQL dengan instance AlloyDB yang cocok yang Anda buat di bagian tolok ukur AlloyDB dalam dokumen ini.
- Kapasitas penyimpanan: Kustom, 1500 GB
- Aktifkan peningkatan penyimpanan otomatis
- Enkripsi: Google-owned and Google-managed encryption key
- Koneksi: IP Pribadi
- Jaringan:
default
- IP Publik: Diaktifkan
- Jaringan:
Klik Create instance.
Setelah instance PostgreSQL dibuat, catat alamat IP Pribadi. Anda menggunakan IP sebagai
PGHOST
untuk membuat koneksi dengan tolok ukur.Sediakan instance Cloud SQL untuk PostgreSQL. Untuk menjalankan tolok ukur OLTP pilihan Anda, Anda memerlukan mesin klien dengan daya CPU yang signifikan di zona yang sama dengan instance Cloud SQL untuk PostgreSQL utama di Cloud SQL.
Opsional: Sebagai alternatif untuk langkah sebelumnya, Anda dapat menggunakan mesin klien yang sama yang Anda siapkan untuk benchmarking AlloyDB, asalkan hal berikut benar:
- Mesin klien berada di zona yang sama dengan instance utama PostgreSQL (Cloud SQL untuk PostgreSQL) yang baru.
- Komputer klien memenuhi persyaratan CPU, RAM, dan ukuran disk minimum.
Dalam panduan tolok ukur ini, Anda menggunakan kembali mesin klien saat mesin tersebut ditempatkan di zona yang sama dengan instance utama, dan saat mesin tersebut cukup besar untuk membuat server mencapai kapasitas penuhnya.
Jika Anda membuat mesin klien baru, siapkan mesin driver benchmark. Jika tidak, ikuti petunjuk dalam panduan ini untuk menjalankan tolok ukur yang ingin Anda jalankan.
Menyiapkan dan menyediakan database serta mesin klien
Mulai tolok ukur dengan membuat cluster dan instance AlloyDB. Kecuali jika ditentukan lain, informasi dalam dokumen ini didasarkan pada 16 vCPU dengan RAM 128 GB sebagai instance AlloyDB utama.
Buat cluster dan instance AlloyDB
Menyediakan mesin klien
Untuk menjalankan benchmark OLTP, Anda memerlukan komputer klien dengan daya pemrosesan yang memadai. Alat benchmark seperti HammerDB dan pgbench berjalan secara sangat paralel dan menggunakan banyak CPU. Mesin klien tidak boleh menjadi hambatan saat Anda menjalankan benchmark OLTP.
Kecuali jika ditentukan lain, petunjuk dalam dokumen ini menggunakan mesin E2-standard-32 dengan disk 128 GB sebagai klien untuk benchmark OLTP guna mendorong instance AlloyDB pada mesin 16 vCPU dengan RAM 128 GB. Anda harus membuat mesin klien di zona yang sama dengan instance utama AlloyDB.
Untuk menjalankan benchmark TPC-C pada instance utama AlloyDB dengan 16 CPU virtual, ikuti langkah-langkah berikut untuk membuat VM Compute Engine dan menyediakan mesin klien:
Menyiapkan mesin driver benchmark
Setelah menginstal dan menyiapkan database serta komputer klien, Anda mengonfigurasi komputer klien yang berjalan di Google Cloud, tempat Anda menginstal alat tolok ukur seperti HammerDB dan pgbench.
Untuk menyiapkan mesin driver tolok ukur, ikuti langkah-langkah berikut:
Melakukan pembersihan tolok ukur
Jika Anda berencana menjalankan beberapa benchmark secara berurutan, Anda harus melakukan pembersihan benchmark di antara setiap benchmark untuk memastikan hasil benchmark yang akurat dan andal.
Pembersihan tolok ukur memastikan bahwa efek sisa dari tolok ukur sebelumnya tidak memengaruhi pengukuran performa tolok ukur baru. Pembersihan tolok ukur juga membantu memastikan konsistensi dan pengulangan hasil tolok ukur, yang penting untuk membuat perbandingan yang bermakna antara sistem yang berbeda atau mengidentifikasi area untuk pengoptimalan dalam hardware, software, atau konfigurasi.
Ikuti langkah-langkah berikut untuk melakukan pembersihan tolok ukur sebelum Anda menjalankan tolok ukur lain:
Menjalankan Benchmark TPC-C
HammerDB adalah alat tolok ukur yang mencakup penerapan tolok ukur TPC-C untuk mengevaluasi performa sistem OLTP. Implementasi TPC-C HammerDB memungkinkan Anda menyimulasikan beban kerja yang mirip dengan benchmark TPC-C, termasuk campuran transaksi yang meniru perilaku lingkungan pemasok grosir.
HammerDB mengukur performa sistem dalam hal transaksi per menit (TPM) dan membuat laporan yang mencakup statistik mendetail dan metrik performa. Selain itu, HammerDB mendukung penyesuaian parameter benchmark, sehingga pengguna dapat menyesuaikan ukuran database, jumlah gudang, dan karakteristik beban kerja lainnya untuk menyimulasikan berbagai skenario.
Skenario evaluasi performa
Performa tolok ukur TPC-C dievaluasi menggunakan metode berikut:
Menyiapkan mesin klien
Memuat data TPC-C ke dalam database
Langkah pemuatan mengacu pada proses mengisi database benchmark dengan data awal sebelum menjalankan uji performa.
Selama langkah pemuatan, database diisi dengan sejumlah gudang, pelanggan, dan entitas lainnya sesuai dengan spesifikasi TPC-C. Tujuan langkah pemuatan adalah untuk membuat workload yang realistis untuk pengujian performa, dan untuk memastikan bahwa hasil pengujian dapat dibandingkan di berbagai sistem.
Setelah langkah pemuatan selesai, database berada dalam status yang konsisten dengan set data awal yang ditentukan, siap digunakan untuk uji tolok ukur TPC-C.
Untuk memuat database TPC-C, ikuti langkah-langkah berikut:
Dalam konfigurasi TPC-C yang di-cache 30% (dengan 3.200 gudang), ukuran database tpcc
diperkirakan sekitar 300 GB.
Dalam konfigurasi TPC-C yang 100% di-cache (dengan 576 gudang), ukuran database tpcc
diperkirakan sekitar 55 GB.
Menjalankan benchmark TPC-C
Sekarang Anda siap menjalankan uji performa TPC-C. Benchmark TPC-C dijalankan menggunakan database yang diisi dari langkah pemuatan. Benchmark menghasilkan serangkaian transaksi yang menyimulasikan lingkungan bisnis umum, termasuk entri pesanan, pemrosesan pembayaran, dan pengelolaan inventaris. Beban kerja diukur dalam transaksi per menit (TPM), yang mewakili jumlah transaksi bisnis lengkap yang dapat ditangani sistem dalam satu menit.
Langkah menjalankan dirancang untuk menguji sistem database dalam kondisi yang realistis dan memberikan cara standar untuk mengukur performa yang dapat Anda bandingkan di berbagai sistem database. Vendor dan pengguna sering menggunakan hasil benchmark TPC-C untuk mengevaluasi performa berbagai sistem database dan konfigurasi hardware.
Untuk menjalankan benchmark TPC-C, ikuti langkah-langkah berikut:
Menganalisis hasil benchmark
Dalam tolok ukur TPC-C, Pesanan Baru Per Menit (NOPM) dan Transaksi Per Menit (TPM) adalah metrik performa yang digunakan untuk mengukur performa sistem database.
Melihat hasil dengan database TPC-C yang di-cache 30% pada mesin 16 vCPU
Untuk mengekstrak angka performa untuk skenario ini, gunakan perintah berikut:
grep NOPM results/run-tpcc.out
Berikut adalah output yang diharapkan:
Vuser 1:TEST RESULT : System achieved 252970 NOPM from 582385 PostgreSQL TPM
Dengan database TPC-C yang di-cache sebesar 30% di mesin 16 vCPU (dengan NUM_WAREHOUSE=3200
dan NUM_USERS=256
), Anda akan melihat 252.970 tpm-C (New Order Per Minute)
dari kumulatif 582.385 TPM AlloyDB.
Melihat hasil dengan database TPC-C yang di-cache 100% pada mesin 16 vCPU
Pada database TPC-C yang 100% di-cache di mesin 16 vCPU (dengan NUM_WAREHOUSE=576
dan NUM_USERS=256
), Anda mengamati 428.316 tpm-C (Pesanan Baru Per Menit) dari
TPM AlloyDB kumulatif sebesar 974.264.
Untuk mengekstrak angka performa untuk skenario ini, gunakan perintah berikut:
grep NOPM results/tpcc-run.out
Berikut adalah output yang diharapkan:
Vuser 1:TEST RESULT : System achieved 428316 NOPM from 974264 PostgreSQL TPM
Ringkasan hasil performa di mesin 16 vCPU
Tabel berikut merangkum hasil performa benchmark untuk mesin 16 vCPU:
Skenario TPC-C | NUM_WAREHOUSE | NUM_USERS | NOPM | TPM kumulatif |
---|---|---|---|---|
30% di-cache | 3200 | 256 | 252.970 | 582.385 |
100% di-cache | 576 | 256 | 428.316 | 974.264 |
Mengamati metrik performa database
Untuk lebih memahami perilaku sistem database Anda, gunakan alat pemantauan AlloyDB untuk mengamati metrik sistem penting seperti penggunaan CPU, penggunaan memori, dan transaksi per detik. Untuk informasi selengkapnya, lihat Memantau performa instance.
Misalnya, setelah menjalankan tolok ukur ini, Anda dapat mengamati di halaman Overview AlloyDB di konsol Google Cloud bahwa penggunaan CPU rata-rata untuk menjalankan TPC-C yang di-cache 100% hampir 90%.
Menjalankan tolok ukur TPC-C pada instance AlloyDB 64 vCPU
Untuk menjalankan tolok ukur TPC-C pada instance AlloyDB 64 vCPU, Anda mengikuti langkah-langkah penyiapan yang sama seperti pada Menjalankan tolok ukur TPC-C, tetapi Anda menggunakan jenis mesin yang berbeda.
Menyiapkan AlloyDB dan mesin klien
Menjalankan benchmark
Menganalisis hasil benchmark
Tabel berikut merangkum hasil performa benchmark pada mesin dengan 64 vCPU:
Mode tolok ukur | NUM_WAREHOUSE | NUM_USERS | NOPM | TPM kumulatif |
---|---|---|---|---|
30% di-cache | 12800 | 1024 | 589.598 | 1.371.160 |
100% di-cache | 2304 | 1024 | 716.138 | 1.665.438 |
Menjalankan benchmark TPC-B pgbench
TPC-B (Transaction Processing Performance Council Benchmark B) adalah salah satu mode tolok ukur yang tersedia di pgbench, alat tolok ukur untuk PostgreSQL. TPC-B menyimulasikan skenario perbankan di mana beberapa teller menjalankan transaksi di akun pelanggan. Beban kerja terdiri dari jenis transaksi berikut:
Benchmark mengukur performa sistem database dengan menyimulasikan campuran transaksi ini dan mengukur jumlah transaksi per detik yang dapat ditangani oleh sistem.
Mode TPC-B di pgbench menghasilkan database sintetis dan menyimulasikan campuran transaksi yang menyerupai beban kerja TPC-B, tetapi tidak disertifikasi secara resmi oleh organisasi TPC. Oleh karena itu, meskipun mode TPC-B di pgbench memberikan perkiraan performa TPC-B yang berguna, jangan gunakan mode ini untuk mengklaim kepatuhan terhadap standar TPC-B.
Skenario untuk mengukur performa
Bagian ini menjelaskan cara mengukur performa TPC-B dalam mode penting berikut. Satu-satunya parameter yang
berbeda dalam mode ini adalah nilai parameter SCALE_FACTOR
.
Skenario database yang di-cache sebagian
Dalam skenario ini, Anda akan menyiapkan dan melakukan inisialisasi database besar (berukuran sekitar 650 GB) menggunakan --scale= 50000
. Memiliki database besar yang tidak muat dalam memori dan menyebabkan I/O disk yang signifikan memberikan representasi realistis dari banyak workload produksi.
Database besar yang menyebabkan I/O disk yang signifikan dapat menggarisbawahi pentingnya desain database dan pengoptimalan kueri. Database besar juga dapat memunculkan masalah performa terkait I/O disk, seperti akses disk yang lambat atau kueri yang tidak efisien, yang mungkin tidak terlihat pada database kecil atau database yang sepenuhnya berada di memori.
Skenario database yang di-cache sepenuhnya
Dalam skenario ini, Anda menyiapkan dan melakukan inisialisasi database berukuran sekitar 60 GB menggunakan --scale=4000
sehingga database tersebut berada di buffer pool. Membuat tolok ukur
database yang berada di memori penting karena memungkinkan Anda menilai
performa maksimum sistem database dalam lingkungan yang terkontrol.
Database yang berada di memori menyimpan semua data di kumpulan buffer PostgreSQL, sehingga menghilangkan hambatan I/O yang dapat terjadi saat mengakses data dari disk. Mode ini dapat membantu mengidentifikasi hambatan performa yang tidak terkait dengan I/O, seperti penggunaan CPU atau masalah penguncian, yang mungkin tidak terlihat saat Anda melakukan benchmark database yang mengandalkan I/O disk.
Menyiapkan server database dan mesin klien
Untuk menyiapkan infrastruktur guna menjalankan benchmark TPC-B pgbench, ikuti langkah-langkah berikut:
Menjalankan benchmark TPC-B pgbench
Menganalisis hasil benchmark
Periksa output perintah sebelumnya dalam file
~/results/alloydb/pgbench/pgbench.run.out
. Jumlah TPS harus
mendekati jumlah yang ditampilkan dalam database yang di-cache sepenuhnya dan dalam
skenario database yang di-cache sebagian.
Hasil dengan database yang di-cache sepenuhnya
Output perintah terakhir di Jalankan benchmark TPC-B pgbench
akan mirip dengan berikut, dengan --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)
Untuk lebih memahami perilaku sistem database, Anda dapat memantau metrik sistem seperti penggunaan CPU, penggunaan memori, dan transaksi per detik menggunakan konsol Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Memantau instance.
Hasil dengan database yang di-cache sebagian
Output perintah terakhir di Jalankan benchmark TPC-B pgbench
akan mirip dengan berikut, dengan --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)
Ringkasan hasil performa untuk tolok ukur TPC-B pgbench
Tabel berikut merangkum hasil performa untuk benchmark TPC-B pgbench:
Skenario TPC-B | SCALE_FACTOR | TPS | Penggunaan CPU (%) |
---|---|---|---|
Di-cache sebagian | 50000 | 17.460 | 96% |
Di-Cache Sepenuhnya | 4000 | 21.750 | 94% |
Menjalankan benchmark Khusus Penyisipan Indeks
Benchmark Index Insert Only adalah skenario yang sangat konkuren dan intensif tulis
yang disesuaikan di bagian ini untuk menunjukkan manfaat performa
AlloyDB untuk sebagian besar aplikasi OLTP. Untuk menjalankan benchmark ini, Anda membuat beberapa indeks pada tabel pgbench_history
, lalu berulang kali melakukan operasi INSERT pada tabel pgbench_history
dari beberapa koneksi klien.
Tolok ukur Hanya Sisipkan Indeks mengukur performa penyisipan data ke dalam tabel database dengan berfokus secara khusus pada dampak indeks terhadap operasi penulisan. Tolok ukur ini memungkinkan Anda memahami seberapa cepat baris baru dapat ditambahkan ke tabel dengan dan tanpa indeks, yang menyoroti potensi perlambatan yang disebabkan oleh pemeliharaan indeks selama penyisipan.
AlloyDB meningkatkan performa tulis PostgreSQL, yang juga meningkatkan kualitas workload OLTP. Untuk meningkatkan performa skenario OLTP yang intensif tulis, AlloyDB menawarkan inovasi arsitektur termasuk lapisan cache bertingkat untuk membantu operasi baca, dan teknologi mesin penyimpanan terdistribusi dan sangat skalabel untuk operasi tulis.
Menyiapkan AlloyDB dan mesin klien
Untuk menyiapkan infrastruktur guna menjalankan tolok ukur Penyisipan Khusus Indeks, ikuti langkah-langkah berikut:
Menjalankan benchmark Penyisipan Indeks Saja
Menganalisis hasil benchmark
Verifikasi output perintah sebelumnya dalam file /tmp/pgbench-index-insert-only-run.out
. Anda akan melihat sekitar 52 ribu transaksi per detik dan tingkat penggunaan CPU sekitar 88% selama uji tolok ukur ini, seperti yang ditunjukkan dalam contoh output berikut.
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)
Menjalankan benchmark Select Only pada Instance 64 vCPU
pgbench mendukung skenario bawaan khusus pemilihan yang berulang kali menjalankan kueri SELECT dari beberapa koneksi klien terhadap database tertentu. Benchmark ini digunakan untuk mengukur performa baca database, tanpa menimbulkan overhead operasi modifikasi data seperti INSERT, UPDATE, atau DELETE. Kueri SELECT ini adalah kueri penelusuran titik yang merupakan jenis kueri select tercepat dan paling efisien karena melibatkan akses hanya satu baris data langsung dari struktur indeks.
Menjalankan benchmark Hanya Pilih membantu Anda mencapai hal berikut:
Menyiapkan AlloyDB dan mesin klien
Siapkan AlloyDB dan mesin klien pada jenis mesin 64 vCPU.
Menjalankan benchmark Hanya Pilih
Menganalisis hasil benchmark
Anda akan mengamati sekitar 467 ribu transaksi per detik dan rasio penggunaan CPU sekitar 95% selama uji tolok ukur ini, seperti yang ditunjukkan dalam contoh output berikut.
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)
Ringkasan hasil benchmark AlloyDB
Tabel berikut merangkum hasil tolok ukur AlloyDB berdasarkan pengujian yang dilakukan dalam dokumen ini.
Ringkasan performa TPC-C HammerDB
Jenis Mesin AlloyDB | TPC-C Workload Scenario | NUM_WAREHOUSE | NUM_USERS | Pesanan Baru Per Menit (NOPM) | TPM kumulatif | Dikonversi ke TPS |
---|---|---|---|---|---|---|
16vCPU | 30% di-cache | 3200 | 256 | 252.970 | 582.385 | 9.706 |
16vCPU | 100% di-cache | 576 | 256 | 428.316 | 974.264 | 16.238 |
64vCPU | 30% di-cache | 12800 | 1024 | 589.598 | 1.371.160 | 22.853 |
64vCPU | 100% di-cache | 2304 | 1024 | 716.138 | 1.665.438 | 27.757 |
Ringkasan performa pgbench
Jenis Mesin AlloyDB | Skenario Beban Kerja pgbench | Faktor Skala | TPS | CPU % |
---|---|---|---|---|
16vCPU | TPC-B Like, Fully Cached | 4000 | 20.359 | 96% |
16vCPU | TPC-B Like, Partially Cached | 50000 | 14.060 | 94% |
16vCPU | Hanya sisipan indeks | 25000 | 51.742 | 88% |
64vCPU | Throughput Maks. (Khusus Pilih) | 15000 | 467.583 | 95% |
Menjalankan tolok ukur OLTP di Cloud SQL untuk PostgreSQL
Anda dapat menguji performa OLTP yang setara di PostgreSQL di Cloud SQL untuk PostgreSQL pada jenis mesin 16 vCPU untuk analisis komparatif. Bagian ini menjelaskan cara menyiapkan Cloud SQL untuk PostgreSQL (atau server PostgreSQL apa pun yang di-deploy di infrastruktur pilihan Anda) yang sebanding dengan penyiapan AlloyDB yang digunakan dalam panduan ini untuk mengukur performa OLTP. Dalam skenario ini, Anda harus memilih SKU 16vCPU, mengaktifkan ketersediaan tinggi (HA), dan melakukan pra-konfigurasi dengan penyimpanan.