Solusi Cloud PostgreSQL Terkelola Benchmarking:Bagian Kedua - Amazon RDS

Ini adalah bagian kedua dari multi-seri Solusi Cloud PostgreSQL Terkelola Benchmarking . Di Bagian 1 saya menyajikan ikhtisar alat yang tersedia, saya membahas alasan penggunaan Prosedur Tolok Ukur AWS untuk Aurora, serta versi PostgreSQL yang akan digunakan, dan saya meninjau Amazon Aurora PostgreSQL 10.6.

Di bagian ini, pgbench dan sysbench akan dijalankan melawan Amazon RDS untuk PostgreSQL 11.1. Pada saat penulisan ini, versi PostgreSQL terbaru adalah 11.2 dirilis sekitar sebulan yang lalu.

Sebaiknya Anda berhenti sejenak untuk meninjau dengan cepat versi PostgreSQL yang saat ini tersedia di cloud:

• Amazon Aurora PostgreSQL 10.6
• Amazon RDS untuk PostgreSQL 11.1
• Google Cloud SQL untuk PostgreSQL 9.6
• Microsoft Azure PostgreSQL 10.5

Amazon kembali menjadi pemenang, dengan penawaran RDS-nya, dengan menyediakan PostgreSQL versi terbaru. Seperti yang diumumkan di forum RDS, AWS membuat PostgreSQL 11.1 tersedia pada 13 Maret, empat bulan setelah rilis komunitas.

Menyiapkan Lingkungan

Beberapa catatan tentang kendala yang terkait dengan pengaturan lingkungan dan menjalankan benchmark, poin yang dibahas secara lebih rinci selama Bagian 1 dari seri ini:

• Tidak ada perubahan pada setelan GUC default penyedia cloud.
• Koneksi dibatasi hingga maksimum 1.000 karena patch AWS untuk pgbench tidak diterapkan dengan benar. Pada catatan terkait, saya harus mengunduh tambalan waktu AWS dari pengiriman pgsql-hackers ini karena tidak lagi tersedia di tautan yang disebutkan dalam panduan.
• Jaringan yang Disempurnakan harus diaktifkan untuk instance klien.
• Basis data tidak menyertakan replika.
• Penyimpanan database tidak dienkripsi.
• Klien dan instans target berada di zona ketersediaan yang sama.

Pertama, siapkan klien dan instance database:

• Klien adalah instans EC2 r4.8xlarge sesuai permintaan:
  • vCPU:32 (16 Core x 2 Thread/Core)
  • RAM:244 GiB
  • Penyimpanan:EBS Dioptimalkan
  • Jaringan:10 Gigabit
  Konfigurasi Instance Klien
• Kluster DB adalah db.r4.2xlarge sesuai permintaan:
  • vCPU:8
  • RAM:61GiB
  • Penyimpanan:EBS Dioptimalkan
  • Jaringan:1.750 Mbps Max Bandwidth pada koneksi hingga 10 Gbps
  Konfigurasi Instance Database

Selanjutnya, instal dan konfigurasikan alat benchmark, pgbench dan sysbench, dengan mengikuti petunjuk di panduan Amazon.

Langkah terakhir dalam menyiapkan lingkungan adalah mengonfigurasi parameter koneksi PostgreSQL. Salah satu cara melakukannya adalah dengan menginisialisasi variabel lingkungan di .bashrc. Selain itu, kita perlu mengatur jalur ke binari dan pustaka PostgreSQL:

ekspor PGHOST=benchmark.ctfirtyhadgr.us-east-1.rds.amazonaws.com

export PGHOST=benchmark.ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGUSER=postgres
export PGPASSWORD=postgres
export PGDATABASE=postgres
export PATH=$PATH:/usr/local/pgsql/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
Verify that everything is in place:
[[email protected] ~]# psql --version
psql (PostgreSQL) 11.1
[[email protected] ~]# pgbench --version
pgbench (PostgreSQL) 11.1
[[email protected] ~]# sysbench --version
sysbench 0.5

Menjalankan Tolok Ukur

pgench

Pertama, inisialisasi database pgbench.

[[email protected] ~]# pgbench -i --fillfactor=90 --scale=10000

Proses inisialisasi membutuhkan beberapa waktu, dan saat dijalankan menghasilkan output berikut:

dropping old tables...
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
creating tables...
generating data...
100000 of 1000000000 tuples (0%) done (elapsed 0.06 s, remaining 599.79 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.15 s, remaining 739.16 s)
300000 of 1000000000 tuples (0%) done (elapsed 0.22 s, remaining 742.21 s)
400000 of 1000000000 tuples (0%) done (elapsed 0.33 s, remaining 814.64 s)
500000 of 1000000000 tuples (0%) done (elapsed 0.41 s, remaining 825.82 s)
600000 of 1000000000 tuples (0%) done (elapsed 0.51 s, remaining 854.13 s)
700000 of 1000000000 tuples (0%) done (elapsed 0.66 s, remaining 937.01 s)
800000 of 1000000000 tuples (0%) done (elapsed 1.52 s, remaining 1897.42 s)
900000 of 1000000000 tuples (0%) done (elapsed 1.66 s, remaining 1840.08 s)

...

500600000 of 1000000000 tuples (50%) done (elapsed 814.78 s, remaining 812.83 s)
500700000 of 1000000000 tuples (50%) done (elapsed 814.81 s, remaining 812.53 s)
500800000 of 1000000000 tuples (50%) done (elapsed 814.83 s, remaining 812.23 s)
500900000 of 1000000000 tuples (50%) done (elapsed 815.11 s, remaining 812.19 s)
501000000 of 1000000000 tuples (50%) done (elapsed 815.20 s, remaining 811.94 s)

...

999200000 of 1000000000 tuples (99%) done (elapsed 1645.02 s, remaining 1.32 s)
999300000 of 1000000000 tuples (99%) done (elapsed 1645.17 s, remaining 1.15 s)
999400000 of 1000000000 tuples (99%) done (elapsed 1645.20 s, remaining 0.99 s)
999500000 of 1000000000 tuples (99%) done (elapsed 1645.23 s, remaining 0.82 s)
999600000 of 1000000000 tuples (99%) done (elapsed 1645.26 s, remaining 0.66 s)
999700000 of 1000000000 tuples (99%) done (elapsed 1645.28 s, remaining 0.49 s)
999800000 of 1000000000 tuples (99%) done (elapsed 1645.51 s, remaining 0.33 s)
999900000 of 1000000000 tuples (99%) done (elapsed 1645.77 s, remaining 0.16 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 1646.03 s, remaining 0.00 s)
vacuuming...
creating primary keys...
total time: 5538.86 s (drop 0.00 s, tables 0.01 s, insert 1647.08 s, commit 0.03 s, primary 1251.60 s, foreign 0.00 s, vacuum 2640.14 s)
done.

Setelah bagian itu selesai, verifikasi bahwa database PostgreSQL telah diisi. Versi sederhana dari kueri penggunaan disk berikut dapat digunakan untuk mengembalikan ukuran database PostgreSQL:

SELECT
   d.datname AS Name,
   pg_catalog.pg_get_userbyid(d.datdba) AS Owner,
   pg_catalog.pg_size_pretty(pg_catalog.pg_database_size(d.datname)) AS SIZE
FROM pg_catalog.pg_database d
WHERE d.datname = 'postgres';

…dan hasilnya:

  name   |  owner   |  size
----------+----------+--------
postgres | postgres | 160 GB
(1 row)

Setelah semua persiapan selesai, kita dapat memulai tes pgbench baca/tulis:

[[email protected] ~]# pgbench --protocol=prepared -P 60 --time=600 --client=1000 --jobs=2048

Setelah 10 menit kita mendapatkan hasilnya:

starting vacuum...end.
progress: 60.0 s, 878.3 tps, lat 1101.258 ms stddev 339.491
progress: 120.0 s, 885.2 tps, lat 1132.301 ms stddev 292.551
progress: 180.0 s, 656.3 tps, lat 1522.102 ms stddev 666.017
progress: 240.0 s, 436.8 tps, lat 2277.140 ms stddev 524.603
progress: 300.0 s, 742.2 tps, lat 1363.558 ms stddev 578.541
progress: 360.0 s, 866.4 tps, lat 1146.972 ms stddev 301.861
progress: 420.0 s, 878.2 tps, lat 1143.939 ms stddev 304.396
progress: 480.0 s, 872.7 tps, lat 1139.892 ms stddev 304.421
progress: 540.0 s, 881.0 tps, lat 1132.373 ms stddev 311.890
progress: 600.0 s, 729.3 tps, lat 1366.517 ms stddev 867.784
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: prepared
number of clients: 1000
number of threads: 1000
duration: 600 s
number of transactions actually processed: 470582
latency average = 1274.340 ms
latency stddev = 544.179 ms
tps = 782.084354 (including connections establishing)
tps = 783.610726 (excluding connections establishing)

sysbench

Langkah pertama adalah menambahkan beberapa data:

sysbench --test=/usr/local/share/sysbench/oltp.lua \
      --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \
      --pgsql-db=postgres \
      --pgsql-user=postgres \
      --pgsql-password=postgres \
      --pgsql-port=5432 \
      --oltp-tables-count=250\
      --oltp-table-size=450000 \
      prepare

Perintah membuat 250 tabel, setiap tabel memiliki 2 indeks:

sysbench 0.5:  multi-threaded system evaluation benchmark

Creating table 'sbtest1'...
Inserting 450000 records into 'sbtest1'
Creating secondary indexes on 'sbtest1'...
Creating table 'sbtest2'...
...
Creating table 'sbtest250'...
Inserting 450000 records into 'sbtest250'
Creating secondary indexes on 'sbtest250'...

Mari kita lihat indeks:

postgres=> \di
                        List of relations
Schema |         Name          | Type  |  Owner   |      Table
--------+-----------------------+-------+----------+------------------
public | k_1                   | index | postgres | sbtest1
public | k_10                  | index | postgres | sbtest10
public | k_100                 | index | postgres | sbtest100
public | k_101                 | index | postgres | sbtest101
public | k_102                 | index | postgres | sbtest102
public | k_103                 | index | postgres | sbtest103

...

public | k_97                  | index | postgres | sbtest97
public | k_98                  | index | postgres | sbtest98
public | k_99                  | index | postgres | sbtest99
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 | sbtest100_pkey        | index | postgres | sbtest100
public | sbtest101_pkey        | index | postgres | sbtest101
public | sbtest102_pkey        | index | postgres | sbtest102
public | sbtest103_pkey        | index | postgres | sbtest103
public | sbtest104_pkey        | index | postgres | sbtest104
public | sbtest105_pkey        | index | postgres | sbtest105

...

public | sbtest97_pkey         | index | postgres | sbtest97
public | sbtest98_pkey         | index | postgres | sbtest98
public | sbtest99_pkey         | index | postgres | sbtest99
public | sbtest9_pkey          | index | postgres | sbtest9
(503 rows)

Terlihat bagus...untuk memulai tes, jalankan saja:

sysbench --test=/usr/local/share/sysbench/oltp.lua \
      --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \
      --pgsql-db=postgres \
      --pgsql-user=postgres \
      --pgsql-password=postgres \
      --pgsql-port=5432 \
      --oltp-tables-count=250 \
      --oltp-table-size=450000 \
      --max-requests=0 \
      --forced-shutdown \
      --report-interval=60 \
      --oltp_simple_ranges=0 \
      --oltp-distinct-ranges=0 \
      --oltp-sum-ranges=0 \
      --oltp-order-ranges=0 \
      --oltp-point-selects=0 \
      --rand-type=uniform \
      --max-time=600 \
      --num-threads=1000 \
      run

Catatan hati-hati:

Penyimpanan RDS tidak “elastis”, artinya ruang penyimpanan yang dialokasikan saat membuat instans harus cukup besar agar sesuai dengan jumlah data yang dihasilkan selama benchmark, atau RDS akan gagal dengan:

FATAL: PQexec() failed: 7 PANIC:  could not write to file "pg_wal/xlogtemp.29144": No space left on device
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

FATAL: failed query: COMMIT
FATAL: failed to execute function `event': 3
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
WARNING:  terminating connection because of crash of another server process

Ukuran penyimpanan dapat ditingkatkan tanpa menghentikan database, namun, saya membutuhkan waktu sekitar 30 menit untuk mengembangkannya dari 200 GiB menjadi 500 GiB:

Dan berikut adalah hasil pengujian sysbench:

sysbench 0.5:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1000
Report intermediate results every 60 second(s)
Random number generator seed is 0 and will be ignored

Forcing shutdown in 630 seconds

Initializing worker threads...

Threads started!

[  60s] threads: 1000, tps: 1070.40, reads: 0.00, writes: 4309.35, response time: 1808.81ms (95%), errors: 0.02, reconnects:  0.00
[ 120s] threads: 1000, tps: 889.68, reads: 0.00, writes: 3575.35, response time: 1951.12ms (95%), errors: 0.02, reconnects:  0.00
[ 180s] threads: 1000, tps: 574.57, reads: 0.00, writes: 2320.62, response time: 3936.73ms (95%), errors: 0.00, reconnects:  0.00
[ 240s] threads: 1000, tps: 232.10, reads: 0.00, writes: 928.43, response time: 10994.37ms (95%), errors: 0.00, reconnects:  0.00
[ 300s] threads: 1000, tps: 242.40, reads: 0.00, writes: 969.60, response time: 9412.39ms (95%), errors: 0.00, reconnects:  0.00
[ 360s] threads: 1000, tps: 257.73, reads: 0.00, writes: 1030.98, response time: 8833.64ms (95%), errors: 0.02, reconnects:  0.00
[ 420s] threads: 1000, tps: 264.65, reads: 0.00, writes: 1036.60, response time: 9192.42ms (95%), errors: 0.00, reconnects:  0.00
[ 480s] threads: 1000, tps: 278.07, reads: 0.00, writes: 1134.27, response time: 7133.76ms (95%), errors: 0.00, reconnects:  0.00
[ 540s] threads: 1000, tps: 250.40, reads: 0.00, writes: 1001.53, response time: 9628.97ms (95%), errors: 0.00, reconnects:  0.00
[ 600s] threads: 1000, tps: 249.97, reads: 0.00, writes: 996.92, response time: 10724.58ms (95%), errors: 0.00, reconnects:  0.00
OLTP test statistics:
   queries performed:
      read:                            0
      write:                           1038401
      other:                           519199
      total:                           1557600
   transactions:                        259598 (428.59 per sec.)
   read/write requests:                 1038401 (1714.36 per sec.)
   other operations:                    519199 (857.18 per sec.)
   ignored errors:                      3      (0.00 per sec.)
   reconnects:                          0      (0.00 per sec.)

General statistics:
   total time:                          605.7086s
   total number of events:              259598
   total time taken by event execution: 602999.7582s
   response time:
         min:                                 55.02ms
         avg:                               2322.82ms
         max:                              13133.36ms
         approx.  95 percentile:            8400.39ms

Threads fairness:
   events (avg/stddev):           259.5980/3.20
   execution time (avg/stddev):   602.9998/2.77

Metrik Tolok Ukur

Metrik dapat ditangkap menggunakan alat pemantauan AWS CloudWatch dan Performance Insights. Berikut beberapa contoh untuk yang penasaran:

Hasil

Kesimpulan

Meskipun menjalankan PostgreSQL versi 10.6, Amazon Aurora jelas mengungguli RDS yang ada di versi 11.1, dan itu tidak mengejutkan. Menurut FAQ Aurora, Amazon berusaha keras untuk meningkatkan kinerja database secara keseluruhan yang dibangun di atas mesin penyimpanan yang didesain ulang.

Seri berikutnya

Bagian selanjutnya adalah tentang Google Cloud SQL untuk PostgreSQL.