PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Đo điểm chuẩn Giải pháp đám mây PostgreSQL được quản lý - Phần thứ tư:Microsoft Azure

Đây là phần thứ 4 và là phần cuối cùng trong loạt bài Đo điểm chuẩn được quản lý PostgreSQLCloud Solutions . Tại thời điểm viết bài này, Microsoft Azure PostgreSQL ở phiên bản 10.7, mới hơn hai đối thủ:Amazon Aurora PostgreSQL ở phiên bản 10.6 và Google Cloud SQL dành cho PostgreSQL ở phiên bản 9.6.

Microsoft quyết định chạy Azure PostgreSQLon Windows:

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

Đối với thử nghiệm cụ thể này không diễn ra quá tốt và tôi sẽ mạo hiểm đoán rằng Microsoft nhận thức rõ những hạn chế, lý do tại sao dưới cái ô của PostgreSQL, họ cũng cung cấp phiên bản xem trước của phiên bản Dữ liệu Citus của PostgreSQL. Cách tiếp cận này tương tự như các phiên bản AWS PostgreSQL, RDS và tương ứng là Aurora.

Xin lưu ý thêm, trong khi thiết lập tài khoản Azure của mình, tôi đã rất ngạc nhiên vì thiếu xác thực 2FA / MFA (Hai yếu tố / Đa yếu tố) mà tôi đã cấp với AWS Virtual MFA của Amazon và Xác minh 2 bước của Google. Microsoft chỉ cung cấp MFA cho khách hàng doanh nghiệp đã đăng ký Active Directory hoặc Office 365. Vì Citus Cloud thực thi 2FA cho cơ sở dữ liệu sản xuất, có lẽ Microsoft không còn bao lâu nữa để triển khai nó trong Azure.

TL; DR

Không có kết quả nào cho Azure. Trên phiên bản cơ sở dữ liệu 8 lõi, giống hệt về số lõi được sử dụng trên AWS và G Cloud, các bài kiểm tra không thể hoàn thành do lỗi cơ sở dữ liệu. Trên phiên bản 16 lõi, pgbench đã hoàn thành và sysbench đã tiến xa đến mức tạo ra 3 bảng đầu tiên, tại thời điểm đó tôi đã làm gián đoạn quá trình. Mặc dù tôi sẵn sàng dành một lượng công sức, thời gian và tiền bạc hợp lý để thực hiện các bài kiểm tra cũng như ghi lại các lỗi và nguyên nhân của chúng, mục tiêu của bài tập này là chạy điểm chuẩn, do đó tôi chưa bao giờ cân nhắc việc theo đuổi bất kỳ cách khắc phục sự cố nâng cao nào hoặc liên hệ Hỗ trợ Azure, tôi cũng chưa hoàn thành bài kiểm tra sysbench trên cơ sở dữ liệu 16 lõi.

Phiên bản đám mây

Khách hàng

Phiên bản ứng dụng khách Azure gần nhất với phiên bản AWS được chọn ở đầu loạt bài blog này, là phiên bản E32s v3 với các thông số kỹ thuật sau:

  • vCPU:32 (16 Cores x 2 Threads / Core)
  • RAM:256 GiB
  • Bộ nhớ:Azure Premium SSD
  • Mạng:Kết nối mạng được tăng tốc lên đến 30Gbps

Đây là ảnh chụp màn hình cổng với các chi tiết về phiên bản:

Chi tiết phiên bản ứng dụng

Mạng tăng tốc được bật theo mặc định khi chọn bất kỳ máy ảo nào được hỗ trợ:

Bật mạng tăng tốc

Vì đó là quy tắc trong đám mây, để đạt được hiệu suất mạng tốt nhất, máy khách và máy chủ phải được đặt trong cùng một khu vực khả dụng mà tôi đã thực hiện bằng cách thiết lập môi trường ở Đông Hoa Kỳ AZ.

Tương tự như đối với Google Cloud, bạn phải tăng hạn ngạch đối với các phiên bản có hơn 10 lõi. Microsoft đã làm điều đó thực sự dễ dàng. Sau khi chuyển sang tài khoản trả phí, tôi đã nhận được xác nhận phê duyệt trước khi tôi có thể hoàn thành câu trả lời của mình trong phiếu giải thích lý do tại sao tôi yêu cầu tăng.

Cơ sở dữ liệu

Khi chọn kích thước phiên bản, tôi đã thử khớp với thông số kỹ thuật của phiên bản được sử dụng trên AWS và Google Cloud:

  • vCPU:8
  • RAM:80 GiB (tối đa)
  • Bộ nhớ:6000 IOPS (kích thước 2TiB ở 3 IOPS / GB)
  • Mạng:2.000 MB / s

Kích thước bộ nhớ thấp bắt nguồn từ bộ nhớ trên mỗi công thức vCore được sử dụng để cấp phát bộ nhớ:

Cấu hình phiên bản cơ sở dữ liệu

Tương tự với Google Cloud và không giống như AWS, bộ nhớ càng lớn thì IOPS càng cao, với tỷ lệ tăng 3:1, tuy nhiên, khi kích thước đạt đến 2TiB, IOPS sẽ được giới hạn ở 6000 IOPS.

Chạy Điểm chuẩn

Thiết lập

Việc thiết lập tuân theo quy trình được mô tả trong các phần trước của loạt bài blog, với bản vá định thời AWS pgbench cho 11.1 áp dụng rõ ràng cho Azure PostgreSQL phiên bản 10.7. Các bản vá cũng có thể được lấy từ các đóng góp của AWS Labs cho kho lưu trữ PostgreSQL Github.

Trong quá trình chạy các điểm chuẩn, tôi đã sử dụng tập lệnh sau đây chỉ tuân theo hướng dẫn của Amazon và trong trường hợp này được điều chỉnh cho phiên bản PostgreSQL trong Azure (10.7). Máy khách chạy 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."

Khi tập lệnh hoàn tất, hãy chỉnh sửa .bashrc để đặt các biến môi trường PostgreSQL. Azure khác biệt về định dạng của tên người dùng PostgreSQL bởi mong đợi một định dạng {username} @ {host} thay vì {username} phổ biến ở khắp mọi nơi:

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

Trước khi bắt đầu kiểm tra, hãy xác minh rằng chúng tôi đang sử dụng đúng phiên bản công cụ khách:

[[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

Khởi tạo cơ sở dữ liệu pgbench. 

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

… Và vài phút sau:

[[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.

Cho đến nay, rất tốt.

Xem nhanh cơ sở dữ liệu để xác nhận rằng nó đã sẵn sàng hoạt động:

[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)

Vì Azure không cho phép thay đổi max_connections và cho rằng đối với trường hợp đã chọn, giới hạn được giới hạn ở mức 960, chúng tôi sẽ phải điều chỉnh số lượng khách hàng pgbench cho phù hợp:

[[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

Và nó đây, tiếng nấc đầu tiên.

Kiểm tra nhanh độ phân giải DNS của máy chủ không cho thấy bất kỳ vấn đề nào:

[[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

Xem lại nhật ký màn hình của tôi cho thấy rằng gần một nửa số kết nối đã bị chấm dứt:

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

pg_stat_activity kể một câu chuyện chi tiết hơn - chúng tôi tăng đột biến ở 950 kết nối:

[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)

… Tuy nhiên, theo dõi truy vấn trên cho thấy số lượng kết nối giảm đột ngột từ 950 xuống còn 628, chỉ trong 10 giây:

[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)

Để khắc phục sự cố DNS, tôi đã chỉ định PGHOST địa chỉ IP máy chủ:

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

Với cách giải quyết đó tại chỗ, tôi bắt đầu lại quá trình kiểm tra:

[[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)

Thoạt nhìn, mọi thứ dường như đã diễn ra ổn thỏa, tuy nhiên, các giá trị độ trễ cực cao, cùng với các vấn đề DNS trước đó và ứng dụng khách hỗ trợ "mạng tăng tốc", cho thấy có điều gì đó không ổn ở cấp mạng và đó là khả năng nguyên nhân của kết quả tps thấp. Nhưng điều tồi tệ nhất vẫn chưa đến.

Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thức

sysbench

Đầu tiên, hãy tạo các bảng:

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

Điều đó trông không ổn chút nào vì vậy tôi đã kiểm tra nhật ký 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

Mặc dù dịch vụ sẽ tự phục hồi, nhưng tôi quyết định khởi động lại phiên bản để tăng tốc quá trình. 

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

Tại thời điểm này, tôi cũng đã bật thông tin chi tiết về hiệu suất truy vấn:

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

Trước khi khởi động lại tác vụ sysbench, tôi muốn đảm bảo rằng cơ sở dữ liệu hoạt động tốt và do đó tôi đã bắt đầu kiểm tra pgbench thứ hai:

[[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.

Theo trình giám sát truy vấn pg_stat_activity, máy chủ bị chết khi số lượng kết nối đạt đến 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)

Và từ nhật ký PostgreSQL, chúng tôi biết rằng có điều gì đó đã xảy ra dọc theo đường ống kết nối:

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.

Đối mặt với hạn chế trong max_connections và các vấn đề gặp phải trong quá trình kiểm tra pgbench và sysbench, tôi bắt đầu tò mò về việc liệu cơ sở dữ liệu 16 lõi có thể hiện hành vi tương tự hay không.

Phiên bản cơ sở dữ liệu 16 lõi

Trên phiên bản cơ sở dữ liệu 16 lõi, giới hạn max_connections đủ lớn để chứa 1000 máy khách:

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

Điều đó cho phép tôi chạy các lệnh chuẩn giống như tôi đã sử dụng trên các nhà cung cấp dịch vụ đám mây trước đó.

Điểm chuẩn đã hoàn tất thành công và kết quả được hiển thị bên dưới:

pgbench

  • Khởi tạo:
    [[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.
  • Chạy:
    [[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)

Điều đó diễn ra khá tốt, tuy nhiên, không có cách nào hợp lệ để so sánh những kết quả này với những kết quả từ AWS và G Cloud, vì chúng tôi không thử nghiệm trên một nền tảng tương tự. Nhưng điều này đủ tốt để đưa chúng ta đến điểm tiếp theo.

sysbench

Khi các bài kiểm tra pgbench hoàn thành thành công, tôi quyết định tận dụng tối đa khoản tín dụng $ 200 của Azure và xác nhận rằng sysbench nhận được nhiều hơn so với lần chạy trước trên phiên bản 8 lõi:

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'...

Điều đó có vẻ hoạt động tốt và vì tôi đã gần hết ngân sách của mình, tôi quyết định dừng nhiệm vụ.

Hyperscale (Citus)

Mặc dù chưa sẵn sàng sản xuất nhưng tùy chọn này đáng được xem xét vì nó cung cấp các tính năng nâng cao không có trong AWS và G Cloud.

Kết quả của việc mua lại Citus Data, Microsoft cung cấp phiên bản xem trước của sản phẩm PostgreSQL hàng đầu của họ, dưới tên Hyperscale (Citus).

Trình hướng dẫn cổng thông tin giúp việc thiết lập một môi trường phức tạp khác trở nên dễ dàng:

Cấu hình Azure Hyperscale (Citus)

Tôi lưu ý rằng trái ngược với Azure PostgreSQL chạy trên Windows, Hyperscale chạy trên 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)

Thật không may, trong khi Hyperscale hứa hẹn một cuộc hành trình thú vị, tại thời điểm này, tôi không thể tiếp tục chạy thử nghiệm vì max_connections hiện được giới hạn ở mức 300, không có tùy chọn để điều chỉnh, mặc dù khả năng được ghi lại cho Citus PosgreSQL gốc:

[email protected]:5432 citus> show max_connections ;
 max_connections
-----------------
 300
(1 row)
Các tham số có sẵn của Bộ điều phối Hyperscale (Citus) Công nhân Hyperscale (Citus):không có max_connections

Chỉ số điểm chuẩn

Một số chỉ số cho biết hiệu suất và hành vi của máy khách và máy chủ:

Azure Portal Dashboard - Số liệu cho máy khách và máy chủ

Các chỉ số PostgreSQL được thu thập bằng cách sử dụng Thông tin chi tiết về hiệu suất truy vấn:

Azure PostgreSQL - Thông tin chi tiết về hiệu suất truy vấn:5 truy vấn hàng đầu Azure PostgreSQL - Thông tin chi tiết về hiệu suất truy vấn:5 lần chờ hàng đầu

Kết luận

Các tài nguyên liên quan Đo điểm chuẩn Giải pháp đám mây PostgreSQL được quản lý - Phần một:Đo điểm chuẩn Amazon Aurora Giải pháp đám mây PostgreSQL được quản lý - Phần hai:Đo điểm chuẩn Amazon RDS Giải pháp đám mây PostgreSQL được quản lý - Phần ba:Google Cloud

Đầu tiên, nếu bạn đã làm được điều này, cảm ơn bạn đã đọc và nếu bạn tình cờ phát hiện ra bất kỳ lỗi nào có thể khiến môi trường hoạt động sai, tôi rất đánh giá cao phản hồi. Với điều kiện rằng tôi đã bỏ lỡ điều gì đó rõ ràng, tôi sẵn sàng lặp lại các bài kiểm tra.

Sự cố công cụ cơ sở dữ liệu dẫn đến kết xuất hex “NT HARD ERROR” cho biết rằng đã xảy ra điều gì đó ngoài tầm kiểm soát của người dùng và một dịch vụ được quản lý tốt sẽ khôi phục bằng cách tự động hóa hoặc cảnh báo cho các SRE phụ trách. Tôi đã đợi thêm thời gian như vậy có thể xảy ra, mặc dù nó đặt ra câu hỏi rằng người dùng phải đợi bao lâu cho đến khi dịch vụ được khôi phục.

Việc khóa max_connections thành một giá trị dựa trên bậc định giá và vCores đã khiến tôi ngạc nhiên, đặc biệt là sau khi thử nghiệm ba dịch vụ được quản lý khác, với Google Cloud cho phép người dùng định cấu hình thông số mặc dù giá trị mặc định thấp hơn nhiều (600 trên G Cloud so với 960 trên Azure).

Có thể cần phải kiểm tra phiên bản cơ sở dữ liệu trong phạm vi 16 lõi để tránh thay đổi các giá trị mặc định, mặc dù tại thời điểm đó, tôi muốn kiểm tra bằng cách sử dụng các công cụ tốt hơn, chẳng hạn như HammerDB (xem Phần 1 để thảo luận về các công cụ) .


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

  1. org.hibernate.internal.util.config.ConfigurationException:Không thể định vị tài nguyên cfg.xml [/HibernateTest/src/hibernate.cfg.xml]

  2. Cách liệt kê tất cả người dùng trong PostgreSQL

  3. Tạo người dùng với mật khẩu được mã hóa trong PostgreSQL

  4. Chuyển đổi mảng PostgreSQL sang mảng PHP

  5. GROUP hoặc DISTINCT sau khi JOIN trả về các bản sao