PostgreSQL
 sql >> Teknologi Basis Data >  >> RDS >> PostgreSQL

Solusi Cloud PostgreSQL Terkelola Pembandingan - Bagian Empat:Microsoft Azure

Ini adalah bagian ke-4 dan terakhir dari seri Solusi PostgreSQLCloud Terkelola Benchmarking . Pada saat penulisan ini, Microsoft Azure PostgreSQL berada di versi 10.7, lebih baru dari dua pesaing:Amazon Aurora PostgreSQL di versi 10.6 dan Google Cloud SQL untuk PostgreSQL di versi 9.6.

Microsoft memutuskan untuk menjalankan Azure PostgreSQL di Windows:

postgres=> select version();
                        version
------------------------------------------------------------
PostgreSQL 10.7, compiled by Visual C++ build 1800, 64-bit
(1 row)

Untuk tes khusus ini yang tidak berjalan dengan baik, dan saya berani menebak bahwa Microsoft sangat menyadari keterbatasannya, alasan mengapa di bawah payung PostgreSQL mereka juga menawarkan versi pratinjau versi Citus Data dari PostgreSQL. Pendekatannya terlihat mirip dengan rasa AWS PostgreSQL, RDS dan Aurora masing-masing.

Sebagai catatan tambahan, saat menyiapkan akun Azure saya, saya terkejut dengan kurangnya otentikasi 2FA/MFA (Dua-Faktor/Multi-Faktor) yang saya terima dengan AWS Virtual MFA Amazon dan Verifikasi 2 langkah Google. Microsoft menawarkan MFA hanya untuk pelanggan perusahaan yang berlangganan Active Directory atau Office 365. Karena Citus Cloud menerapkan 2FA untuk database produksi, mungkin Microsoft tidak akan jauh-jauh mengimplementasikannya di Azure.

TL;DR

Tidak ada hasil untuk Azure. Pada instans database 8-inti, jumlah core yang identik dengan yang digunakan di AWS dan G Cloud, pengujian gagal diselesaikan karena error database. Pada instance 16-core, pgbench selesai, dan sysbench berhasil membuat 3 tabel pertama di mana saya menghentikan prosesnya. Sementara saya bersedia menghabiskan cukup banyak usaha, waktu, dan uang untuk melakukan tes, dan mendokumentasikan kesalahan dan penyebabnya, tujuan latihan ini adalah menjalankan benchmark, oleh karena itu saya tidak pernah mempertimbangkan untuk melakukan pemecahan masalah lanjutan, atau menghubungi Dukungan Azure, saya juga tidak menyelesaikan tes sysbench pada database 16-core.

Instance Cloud

Klien

Instans klien Azure yang paling dekat dengan instans AWS yang dipilih di awal seri blog ini, adalah instans E32s v3 dengan spesifikasi berikut:

  • vCPU:32 (16 Core x 2 Thread/Core)
  • RAM:256 GiB
  • Penyimpanan:Azure Premium SSD
  • Jaringan:Mempercepat Jaringan hingga 30Gbps

Berikut screenshot portal dengan detail instance:

Detail contoh klien

Jaringan yang Dipercepat diaktifkan secara default saat memilih salah satu mesin virtual yang didukung:

Jaringan yang dipercepat Aktif

Seperti aturan di cloud, untuk mencapai kinerja jaringan terbaik, klien dan server harus berada di zona ketersediaan yang sama, yang saya lakukan dengan menyiapkan lingkungan di AZ AS Timur.

Sama halnya dengan Google Cloud, peningkatan kuota harus diminta untuk instans dengan lebih dari 10 core. Microsoft membuatnya sangat mudah. Setelah beralih ke akun berbayar, saya menerima konfirmasi persetujuan sebelum saya dapat menyelesaikan balasan saya di tiket yang menjelaskan mengapa saya meminta kenaikan.

Basis Data

Dalam memilih ukuran instans, saya mencoba mencocokkan spesifikasi instans yang digunakan di AWS dan Google Cloud:

  • vCPU:8
  • RAM:80 GiB (maksimum)
  • Penyimpanan:6000 IOPS (ukuran 2TiB pada 3 IOPS/GB)
  • Jaringan:2.000 MB/dtk

Ukuran memori yang rendah berasal dari memori per rumus vCore yang digunakan untuk mengalokasikan memori:

Konfigurasi Instance Database

Serupa dengan Google Cloud, dan tidak seperti AWS, semakin besar penyimpanan, semakin tinggi IOPS, dengan peningkatan rasio 3:1, namun, setelah ukurannya mencapai 2TiB, IOPS dibatasi hingga 6000 IOPS.

Menjalankan Tolok Ukur

Penyiapan

Penyiapan mengikuti proses yang dijelaskan di bagian sebelumnya dari seri blog, dengan tambalan waktu pgbench AWS untuk 11.1 diterapkan dengan bersih ke Azure PostgreSQL versi 10.7. Patch juga dapat diperoleh dari kontribusi AWS Labs ke repositori PostgreSQL Github.

Selama menjalankan benchmark, saya menggunakan skrip berikut yang hanya mengikuti panduan Amazon dan dalam hal ini disesuaikan untuk versi PostgreSQL di Azure (10.7). Mesin klien menjalankan CentOS 7.5:

#!/bin/bash

set -eE
trap "exit 1" ERR

yum -y install \
   wget ant git php gnuplot gcc make readline-devel zlib-devel \
   postgresql-jdbc bzr automake libtool patch libevent-devel \
   openssl-devel ncurses-devel

wget https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz
rm -rf postgresql-10.7
tar -xzf postgresql-10.7.tar.gz
cd postgresql-10.7
wget https://s3.amazonaws.com/aurora-pgbench-patches/pgbench-init-timing.patch
patch --verbose -p1 -b  < pgbench-init-timing.patch
./configure
make -j 4 all
make install
cd ..

rm -rf sysbench
git clone -b 0.5 https://github.com/akopytov/sysbench.git
cd sysbench
./autogen.sh
CFLAGS="-L/usr/local/pgsql/lib/ -I /usr/local/pgsql/include/" \
   | ./configure \
      --with-pgsql \
      --without-mysql \
      --with-pgsql-includes=/usr/local/pgsql/include/ \
      --with-pgsql-libs=/usr/local/pgsql/lib/
make
make install
cd sysbench/tests
make install

sed -i \
   '/^export PGHOST=/,/^export LD_LIBRARY_PATH.*pgsql/d' \
   ~/.bashrc
cat << "__eot__" >> ~/.bashrc
export PGHOST=CHANGEME
export PGUSER=postgres
export PGPASSWORD=postgres
export PGDATABASE=postgres
export PGPORT=5432
export PATH=/usr/local/pgsql/bin:/usr/local/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
__eot__

echo "All done."

Setelah skrip selesai, edit .bashrc untuk mengatur variabel lingkungan PostgreSQL. Azure aneh tentang format nama pengguna PostgreSQL dengan mengharapkan format {username}@{host} daripada {username} di mana-mana:

[[email protected] scripts]# psql
psql: FATAL:  Invalid Username specified. Please check the Username and retry connection. The Username should be in <[email protected]> format.

Sebelum memulai pengujian, pastikan kami menggunakan versi alat klien yang benar:

[[email protected] scripts]# psql --version
psql (PostgreSQL) 10.7
[[email protected] scripts]# pgbench  --version
pgbench (PostgreSQL) 10.7
[[email protected] scripts]# sysbench --version
sysbench 0.5

pgench

Inisialisasi database pgbench.

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

…dan beberapa menit kemudian:

[[email protected] scripts]# pgbench -i --fillfactor=90 --scale=10000
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables...
100000 of 1000000000 tuples (0%) done (elapsed 0.04 s, remaining 426.44 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.09 s, remaining 427.22 s)
300000 of 1000000000 tuples (0%) done (elapsed 0.18 s, remaining 600.63 s)
400000 of 1000000000 tuples (0%) done (elapsed 0.21 s, remaining 530.99 s)
500000 of 1000000000 tuples (0%) done (elapsed 0.30 s, remaining 595.12 s)

...

584300000 of 1000000000 tuples (58%) done (elapsed 2421.82 s, remaining 1723.01 s)
584400000 of 1000000000 tuples (58%) done (elapsed 2421.86 s, remaining 1722.32 s)
584500000 of 1000000000 tuples (58%) done (elapsed 2422.81 s, remaining 1722.29 s)
584600000 of 1000000000 tuples (58%) done (elapsed 2422.84 s, remaining 1721.60 s)
584700000 of 1000000000 tuples (58%) done (elapsed 2422.88 s, remaining 1720.92 s)
584800000 of 1000000000 tuples (58%) done (elapsed 2425.06 s, remaining 1721.76 s)
584900000 of 1000000000 tuples (58%) done (elapsed 2425.09 s, remaining 1721.07 s)
585000000 of 1000000000 tuples (58%) done (elapsed 2425.28 s, remaining 1720.50 s)
...

999700000 of 1000000000 tuples (99%) done (elapsed 4142.69 s, remaining 1.24 s)
999800000 of 1000000000 tuples (99%) done (elapsed 4142.95 s, remaining 0.83 s)
999900000 of 1000000000 tuples (99%) done (elapsed 4142.98 s, remaining 0.41 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 4143.92 s, remaining 0.00 s)
vacuum...
set primary keys...
total time: 14805.73 s (insert 4146.94 s, commit 0.02 s, vacuum 6581.15 s, index 4077.61 s)
done.

Sejauh ini, sangat baik.

Lihat sekilas database untuk mengonfirmasi bahwa database siap digunakan:

[email protected]:5432 postgres> \l+
                                                                                                List of databases
      Name        |      Owner      | Encoding |          Collate           |           Ctype            |          Access privileges          |   Size    | Table space |                Description
-------------------+-----------------+----------+----------------------------+----------------------------+-------------------------------------+-----------+------------+--------------------------------------------
azure_maintenance | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 | azure_superuser=CTc/azure_superuser | No Access | pg_default  |
azure_sys         | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 |                                     | 12 MB     | pg_default  |
postgres          | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 |                                     | 160 GB    | pg_default  | default administrative connection database
template0         | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 | =c/azure_superuser                 +| 7865 kB   | pg_default  | unmodifiable empty database
                  |                 |          |                            |                            | azure_superuser=CTc/azure_superuser |           |             |
template1         | azure_superuser | UTF8     | English_United States.1252 | English_United States.1252 | =c/azure_superuser                 +| 7865 kB   | pg_default  | default template for new databases
                  |                 |          |                            |                            | azure_superuser=CTc/azure_superuser |           |             |
(5 rows)

Karena Azure tidak mengizinkan perubahan max_connections dan mengingat bahwa untuk instance yang dipilih, batasnya dibatasi pada 960, kami harus menyesuaikan jumlah klien pgbench yang sesuai:

[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048
starting vacuum...end.
connection to database "postgres" failed:
could not translate host name "postgresql-10-7.postgres.database.azure.com" to address: Name or service not known
connection to database "postgres" failed:
could not translate host name "postgresql-10-7.postgres.database.azure.com" to address: Name or service not known

Dan ini dia, cegukan pertama.

Pemeriksaan cepat resolusi DNS host tidak menunjukkan masalah apa pun:

[[email protected] scripts]# dig +short $PGHOST
cr1.eastus1-a.control.database.windows.net.
191.238.6.43
[[email protected] scripts]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search 11jv1qvdjs5utlhtlyb5vdyeth.bx.internal.cloudapp.net
nameserver 168.63.129.16

Sebuah tinjauan dari screenlog saya menunjukkan bahwa hampir setengah dari koneksi dihentikan:

~$ cat screenlog.1 | nl | grep 'could not translate host name "postgresql-10-7.*Name or service not known' | wc -l
469

pg_stat_activity menceritakan kisah yang lebih mendetail — kami melonjak menjadi 950 koneksi:

[email protected]:5432 postgres> select now(), count(*) from pg_stat_activity where usename = 'postgres' and application_name = 'pgbench';                                now              | count
-------------------------------+-------
2019-05-03 23:39:18.200291+00 |   950
(1 row)

…namun, memantau kueri di atas menunjukkan penurunan jumlah koneksi secara tiba-tiba dari 950 menjadi 628, hanya dalam 10 detik:

[email protected]:5432 postgres> \watch 10
Fri 03 May 2019 11:41:05 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:41:05.044025+00 |   950
(1 row)

...

Fri 03 May 2019 11:43:10 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:43:10.512766+00 |   950
(1 row)

Fri 03 May 2019 11:43:20 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:43:17.419011+00 |   628
(1 row)

Fri 03 May 2019 11:43:30 PM UTC (every 10s)

            now              | count
-------------------------------+-------
2019-05-03 23:43:31.434638+00 |   613
(1 row)

Untuk mengatasi masalah DNS, saya menetapkan PGHOST alamat IP host:

[[email protected] scripts]# set | grep PG
PGDATABASE=postgres
PGHOST=191.238.6.43
[email protected]
PGPORT=5432
[email protected]

Dengan solusi itu, saya memulai kembali pengujian:

[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048
starting vacuum...end.
progress: 61.1 s, 457.7 tps, lat 559.138 ms stddev 1755.888
progress: 120.1 s, 78.8 tps, lat 3883.772 ms stddev 10551.545
progress: 180.1 s, 17.6 tps, lat 50831.708 ms stddev 31214.512
progress: 240.1 s, 15.2 tps, lat 42474.763 ms stddev 32702.050
progress: 300.1 s, 16.1 tps, lat 43584.559 ms stddev 29818.142
progress: 360.1 s, 26.5 tps, lat 36914.096 ms stddev 37152.588
progress: 420.0 s, 33.4 tps, lat 27542.926 ms stddev 37075.457
progress: 480.0 s, 20.2 tps, lat 47149.060 ms stddev 47087.474
progress: 540.0 s, 13.5 tps, lat 55609.260 ms stddev 60394.287
progress: 600.0 s, 36.5 tps, lat 49566.853 ms stddev 99155.598

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: prepared
number of clients: 950
number of threads: 950
duration: 600 s
number of transactions actually processed: 44293
latency average = 12493.888 ms
latency stddev = 40490.231 ms
tps = 60.907130 (including connections establishing)
tps = 64.213520 (excluding connections establishing)

Pada pandangan pertama, tampaknya semuanya berjalan baik-baik saja, namun, nilai latensi yang sangat tinggi, ditambah dengan masalah DNS sebelumnya dan klien yang mengaktifkan "jaringan yang dipercepat", menunjukkan bahwa ada sesuatu yang salah di tingkat jaringan, dan itulah kemungkinannya. penyebab hasil tps rendah. Tapi yang terburuk belum datang.

Unduh Whitepaper Hari Ini Pengelolaan &Otomatisasi PostgreSQL dengan ClusterControlPelajari tentang apa yang perlu Anda ketahui untuk menerapkan, memantau, mengelola, dan menskalakan PostgreSQLUnduh Whitepaper

sysbench

Pertama, buat tabelnya:

sysbench --test=/usr/local/share/sysbench/oltp.lua \
--pgsql-host=${PGHOST} \
--pgsql-db=${PGDATABASE} \
--pgsql-user=${PGUSER} \
--pgsql-password=${PGPASSWORD} \
--pgsql-port=${PGPORT} \
--oltp-tables-count=250\
--oltp-table-size=450000 \
prepare
After a little while:
sysbench 0.5:  multi-threaded system evaluation benchmark

Creating table 'sbtest1'...
FATAL: PQexec() failed: 7 server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

FATAL: failed query: CREATE TABLE sbtest1 (
id SERIAL NOT NULL,
k INTEGER DEFAULT '0' NOT NULL,
c CHAR(120) DEFAULT '' NOT NULL,
pad CHAR(60) DEFAULT '' NOT NULL,
PRIMARY KEY (id)
)
FATAL: failed to execute function `prepare': 3

Itu tidak terlihat bagus sama sekali jadi saya memeriksa log PostgreSQL:

2019-05-03 23:51:12 UTC-5ccbbe4f.88-WARNING:  worker took too long to start; canceled
2019-05-03 23:51:14 UTC-5ccbbe4f.84-PANIC:  could not write to log file 000000010000001F000000CD at offset 13664256, length 8192: Invalid argument
+++ NT HARD ERROR (0xd0000144) +++
    Parameter 0: 0xffffffffc0000005
    Parameter 1: 0x1b80f0f73b
    Parameter 2: 0x1
    Parameter 3: 0x0

Meskipun layanan akan pulih dengan sendirinya, saya memutuskan untuk mem-boot ulang instance untuk mempercepat proses.

2019-05-04 00:43:23 UTC-5ccce02a.2c-HINT:  Is another postmaster already running on port 20108? If not, wait a few seconds and retry.
2019-05-04 00:43:23 UTC-5ccce02a.2c-LOG:  could not bind IPv6 address "::": A socket operation was attempted to an unreachable host.
2019-05-04 00:43:23 UTC-5ccce02a.2c-LOG:  listening on IPv4 address "0.0.0.0", port 20108
2019-05-04 00:43:24 UTC-5ccce02a.2c-LOG:  database system is ready to accept connections
...
2019-05-05 00:03:35 UTC-5cce2856.2c-HINT:  Is another postmaster already running on port 20326? If not, wait a few seconds and retry.
2019-05-05 00:03:35 UTC-5cce2856.2c-LOG:  could not bind IPv6 address "::": A socket operation was attempted to an unreachable host.
2019-05-05 00:03:35 UTC-5cce2856.2c-LOG:  listening on IPv4 address "0.0.0.0", port 20326
2019-05-05 00:03:38 UTC-5cce285a.3c-FATAL:  the database system is starting up
2019-05-05 00:03:38 UTC-5cce285a.3c-LOG:  connection received: host=127.0.0.1 port=47247 pid=60
2019-05-05 00:03:49 UTC-5cce2865.40-FATAL:  the database system is starting up
2019-05-05 00:03:49 UTC-5cce2865.40-LOG:  connection received: host=127.0.0.1 port=47284 pid=64
2019-05-05 00:03:59 UTC-5cce286f.44-FATAL:  the database system is starting up
2019-05-05 00:03:59 UTC-5cce286f.44-LOG:  connection received: host=127.0.0.1 port=47312 pid=68
2019-05-05 00:04:00 UTC-5cce2856.2c-LOG:  database system is ready to accept connections
2019-05-05 00:04:00 UTC-5cce2870.38-LOG:  database system was shut down at 2019-05-05 00:03:34 UTC

Pada titik ini saya juga mengaktifkan wawasan kinerja kueri:

2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  parameter "pgms_wait_sampling.query_capture_mode" changed to "ALL"
2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  parameter "pg_qs.query_capture_mode" changed to "TOP"
2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  received SIGHUP, reloading configuration files
2019-05-05 00:04:13 UTC-5cce2856.2c-LOG:  received SIGHUP, reloading configuration files
2019-05-05 00:04:13 UTC-5cce287a.6c-ERROR:  database "azure_sys" already exists
2019-05-05 00:04:13 UTC-5cce287a.6c-STATEMENT:  CREATE DATABASE azure_sys TEMPLATE template0

Sebelum memulai kembali tugas sysbench, saya ingin memastikan bahwa database sehat, dan oleh karena itu saya menjalankan tes pgbench kedua:

[[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=950 --jobs=2048
starting vacuum...end.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to database "postgres" failed:
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

Menurut monitor permintaan pg_stat_activity, server mati ketika jumlah koneksi mencapai 710:

[email protected]:5432 postgres> \watch 1
Sun 05 May 2019 12:44:11 AM UTC (every 1s)

            now              | count
-------------------------------+-------
2019-05-05 00:44:11.010413+00 |   220
(1 row)

Sun 05 May 2019 12:44:12 AM UTC (every 1s)

            now              | count
-------------------------------+-------
2019-05-05 00:44:12.041667+00 |   231
(1 row)

...

            now              | count
------------------------------+-------
2019-05-05 00:47:33.16533+00 |   710
(1 row)

Sun 05 May 2019 12:47:40 AM UTC (every 1s)

            now              | count
-------------------------------+-------
2019-05-05 00:47:40.524662+00 |   710
(1 row)

Dan dari log PostgreSQL kami mengetahui bahwa sesuatu terjadi di sepanjang pipa koneksi:

2019-05-05 00:44:11 UTC-5cce31da.c60-LOG:  connection received: host=40.114.85.62 port=50925 pid=3168
2019-05-05 00:44:11 UTC-5cce31db.c58-LOG:  connection received: host=40.114.85.62 port=55256 pid=3160
2019-05-05 00:44:11 UTC-5cce31db.c5c-LOG:  connection received: host=40.114.85.62 port=34526 pid=3164
2019-05-05 00:44:11 UTC-5cce31db.c64-LOG:  connection received: host=40.114.85.62 port=1178 pid=3172
...
2019-05-05 00:47:32 UTC-5cce329a.146c-LOG:  connection received: host=40.114.85.62 port=41769 pid=5228
2019-05-05 00:47:33 UTC-5cce3287.1404-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce3288.1428-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce3289.1434-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce3291.1448-LOG:  connection authorized: user=postgresdatabase=postgres SSL enabled (protocol=TLSv1.1, cipher=ECDHE-RSA-AES256-SHA, compression=off)
2019-05-05 00:47:33 UTC-5cce32a3.1484-LOG:  connection received: host=40.114.85.62 port=50296 pid=5252
2019-05-05 00:47:33 UTC-5cce32a5.1488-LOG:  connection received: host=40.114.85.62 port=28304 pid=5256
2019-05-05 00:47:39 UTC-5cce31d2.a24-LOG:  could not send data to client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce31d5.ae8-LOG:  could not receive data from client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce31e3.ee4-LOG:  could not send data to client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce31e9.1054-LOG:  could not receive data from client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:39 UTC-5cce3291.1444-LOG:  could not receive data from client: An existing connection was forcibly closed by the remote host.
2019-05-05 00:47:40 UTC-5cce31cd.8ec-LOG:  could not send data to client: An existing connection was forcibly closed by the remote host.

Menghadapi keterbatasan dalam max_connections dan masalah yang dihadapi selama pengujian pgbench dan sysbench, saya mulai penasaran apakah database 16-core akan menunjukkan perilaku yang sama.

Instance Basis Data 16-Core

Pada instance database 16-inti, batas max_connections cukup besar untuk menampung 1000 klien:

[email protected]:5432 postgres> show max_connections ;
 max_connections
-----------------
 1900
(1 row)

Itu memungkinkan saya untuk menjalankan perintah benchmark yang sama seperti yang saya gunakan pada penyedia cloud sebelumnya.

Benchmark berhasil diselesaikan dan hasilnya ditunjukkan di bawah ini:

pgbench

  • Inisialisasi:
    [[email protected] scripts]# pgbench -i --fillfactor=90 --scale=10000
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables...
100000 of 1000000000 tuples (0%) done (elapsed 0.08 s, remaining 807.39 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.13 s, remaining 628.37 s)
300000 of 1000000000 tuples (0%) done (elapsed 0.16 s, remaining 527.89 s)
...
600100000 of 1000000000 tuples (60%) done (elapsed 2499.90 s, remaining 1665.90 s)
600200000 of 1000000000 tuples (60%) done (elapsed 2500.07 s, remaining 1665.33 s)
...
999900000 of 1000000000 tuples (99%) done (elapsed 4170.91 s, remaining 0.42 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 4171.29 s, remaining 0.00 s)
vacuum...
set primary keys...
total time: 13701.50 s (insert 4173.33 s, commit 0.05 s, vacuum 7098.74 s, index 2429.39 s)
done.
  • Jalankan:
    [[email protected] scripts]# pgbench --protocol=prepared -P 60 --time=600 --client=1000 --jobs=2048
starting vacuum...end.
progress: 81.4 s, 5639.1 tps, lat 80.094 ms stddev 73.213
progress: 120.0 s, 4091.0 tps, lat 224.161 ms stddev 608.523
progress: 180.0 s, 6932.1 tps, lat 145.143 ms stddev 228.925
progress: 240.0 s, 7287.9 tps, lat 136.521 ms stddev 156.643
progress: 300.0 s, 7567.8 tps, lat 132.722 ms stddev 158.754
progress: 360.0 s, 8077.9 tps, lat 123.801 ms stddev 139.033
progress: 420.0 s, 6076.9 tps, lat 163.886 ms stddev 201.121
progress: 480.0 s, 5376.2 tps, lat 186.678 ms stddev 191.270
progress: 540.0 s, 4864.0 tps, lat 205.696 ms stddev 164.261
progress: 600.0 s, 3759.3 tps, lat 266.073 ms stddev 542.717
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: 3614386
latency average = 152.935 ms
latency stddev = 248.593 ms
tps = 6002.082008 (including connections establishing)
tps = 6513.306467 (excluding connections establishing)

Itu berjalan cukup baik, namun, tidak ada cara yang valid untuk membandingkan hasil ini dengan hasil dari AWS dan G Cloud, karena kami tidak menguji pada platform yang serupa. Tapi ini cukup bagus untuk membawa kita ke poin berikutnya.

sysbench

Setelah tes pgbench selesai dengan sukses, saya memutuskan untuk memanfaatkan sepenuhnya kredit Azure $200, dan mengonfirmasi bahwa sysbench lebih jauh dari yang dijalankan sebelumnya pada instans 8-inti:

sysbench \
   --test=/usr/local/share/sysbench/oltp.lua \
   --pgsql-host=191.238.6.43 \
   --pgsql-db=postgres \
   [email protected] \
   [email protected] \
   --pgsql-port=5432 \
   --oltp-tables-count=250 \
   --oltp-table-size=450000 prepare

sysbench 0.5:  multi-threaded system evaluation benchmark

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

Tampaknya itu berfungsi dengan baik, dan karena anggaran saya hampir habis, saya memutuskan untuk menghentikan tugas tersebut.

Hiperscale (Citus)

Meskipun belum siap produksi, opsi ini layak untuk dipertimbangkan, karena menyediakan fitur lanjutan yang tidak tersedia di AWS dan G Cloud.

Sebagai hasil dari akuisisi Citus Data, Microsoft menawarkan versi pratinjau dari produk unggulan PostgreSQL mereka, dengan nama Hyperscale (Citus).

Wizard portal membuat pengaturan lingkungan yang rumit menjadi mudah:

Konfigurasi Azure Hyperscale (Citus)

Saya perhatikan bahwa berbeda dengan Azure PostgreSQL yang berjalan di Windows, Hyperscale berjalan di Linux:

[email protected]:5432 citus> select version();
                                                    version
----------------------------------------------------------------------------------------------------------------
 PostgreSQL 11.2 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609, 64-bit
(1 row)

Sayangnya, sementara Hyperscale menjanjikan perjalanan yang mengasyikkan, saat ini saya tidak dapat melanjutkan menjalankan pengujian karena max_connections saat ini dibatasi hingga 300, tanpa opsi penyesuaian, meskipun kemampuan tersebut didokumentasikan untuk Citus PosgreSQL asli:

[email protected]:5432 citus> show max_connections ;
 max_connections
-----------------
 300
(1 row)
Hyperscale (Citus) Koneksi koordinator parameter yang tersedia Pekerja Hyperscale (Citus):max_connections tidak tersedia

Metrik Tolok Ukur

Beberapa metrik yang menunjukkan kinerja dan perilaku klien dan server:

Dasbor Portal Azure - Metrik untuk klien dan server

Metrik PostgreSQL yang dikumpulkan menggunakan Query Performance Insight:

Azure PostgreSQL - Wawasan Kinerja Kueri:5 Kueri Teratas Azure PostgreSQL - Wawasan Kinerja Kueri:5 Penantian Teratas

Kesimpulan

Referensi terkait Solusi Cloud PostgreSQL Terkelola Benchmarking - Bagian Satu:Amazon Aurora Solusi Cloud PostgreSQL Terkelola Benchmarking - Bagian Dua:Amazon RDS Solusi Cloud PostgreSQL Terkelola Benchmarking - Bagian Tiga:Google Cloud

Pertama, jika Anda sampai sejauh ini, terima kasih telah membaca, dan jika Anda kebetulan menemukan kesalahan yang mungkin menyebabkan lingkungan berperilaku tidak semestinya, saya akan sangat menghargai umpan baliknya. Asalkan saya melewatkan sesuatu yang jelas, saya bersedia mengulangi tes.

Kerusakan mesin database yang mengarah ke hex dump "NT HARD ERROR" menunjukkan bahwa sesuatu di luar kendali pengguna terjadi, dan layanan terkelola yang baik akan pulih melalui otomatisasi atau memperingatkan SRE yang bertanggung jawab. Seandainya saya menunggu lebih lama, hal itu bisa terjadi, meskipun itu menimbulkan pertanyaan tentang berapa lama pengguna harus menunggu sampai layanan dipulihkan.

Mengunci max_connections ke nilai berdasarkan tingkat harga dan vCores mengejutkan saya, terutama setelah menguji tiga layanan terkelola lainnya, dengan Google Cloud memungkinkan parameter dikonfigurasi oleh pengguna, meskipun nilai defaultnya jauh lebih rendah (600 di G Cloud vs 960 di Azure).

Tes dengan instans database dalam rentang 16-inti mungkin diperlukan untuk menghindari perubahan nilai default, meskipun pada saat itu saya lebih suka menguji menggunakan alat yang lebih baik, seperti HammerDB (lihat Bagian 1 untuk diskusi alat) .


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Ubah grup keamanan di Instans Database AWS RDS

  2. Melewati banyak nilai dalam parameter tunggal

  3. Cara mengunduh kolom byte Postgres sebagai file

  4. Instal icu4c versi 63 dengan Homebrew

  5. Impor Perpustakaan psycopg2 tidak dimuat:libssl.1.0.0.dylib