摘要:阿里云,采用與模式類似的方案,解決了進程模式在高并發的情況下性能下降的問題。具體測試結果分析阿里云在高并發下,相比社區版本好很多,更加平穩。阿里云引入了機制后,響應延遲,抖動相比社區版本低了很多。
摘要: 背景 進程模型數據庫,需要為每個會話指派獨立的進程與之服務,在連接數非常多,且大都是活躍連接時,進程調度浪費或引入的開銷甚至遠遠大于實際任務需要的開銷(例如上下文切換,MEMCPY等),性能下降會較為嚴重。
背景
進程模型數據庫,需要為每個會話指派獨立的進程與之服務,在連接數非常多,且大都是活躍連接時,進程調度浪費或引入的開銷甚至遠遠大于實際任務需要的開銷(例如上下文切換,MEMCPY等),性能下降會較為嚴重。
PostgreSQL與Oracle Dedicate Server一樣,屬于進程模型。在非常高并發的情況下,性能會下降比較厲害,通常社區版本可以通過加連接池來解決,例如pgbouncer,但是加連接池也會帶來一些問題:
1、綁定變量無法很好的滿足,當然,PostgreSQL 11會增加類似Oracle cursor force的功能,內部將非綁定變量的SQL轉換為綁定變量。
《PostgreSQL 11 preview - 強制auto prepared statment開關(自動化plan cache)(類似Oracle cursor_sharing force)》
2、連接池會使得跳數增加,增加了延遲。
3、數據庫防火墻配置的變化。從直接控制應用端來源,變成了連接池端來源。(除非修改連接池層的代碼,做到來源IP和端口透傳)
Oracle為了解決性能問題,提出了shared server的概念,類似數據庫端的backend process pool,一個process可能服務于多個client。
PostgreSQL也可以如法炮制,比如阿里云RDS PG內核層面增加了內置的POOL。在高并發的情況下,性能好很多。
測試CASE
1、測試64 ~ 16384個并發
2、測試TPC-B,包含5億數據量。
3、測試logged table與unlogged table
4、測試對比社區PostgreSQL 10 與 阿里云PostgreSQL 10
測試環境準備
1、數據庫使用huge page
《PostgreSQL Huge Page 使用建議 - 大內存主機、實例注意》
2、修改pgbench,支持超過1000個連接的測試
《PostgreSQL 11 preview - pgbench 支持大于1000鏈接(ppoll()代替select())》
https://commitfest.postgresql...
《從PostgreSQL支持100萬個連接聊起》
如果使用ppoll,則pstack pgbench可以看到類似如下信息
Thread 1 (Thread 0x7f3f4d89d840 (LWP 116621)): #0 0x00007f3f4ca4569d in poll () from /lib64/libc.so.6 #1 0x00007f3f4d45a9cf in poll (__timeout=-1, __nfds=1, __fds=0x7ffcd6e13c80) at /usr/include/bits/poll2.h:46 #2 pqSocketPoll (end_time=-1, forWrite=0, forRead=28675152, sock=) at fe-misc.c:1129 #3 pqSocketCheck (conn=conn@entry=0x1b58c50, forRead=forRead@entry=1, forWrite=forWrite@entry=0, end_time=end_time@entry=-1) at fe-misc.c:1071 #4 0x00007f3f4d45aa50 in pqWaitTimed (forRead=forRead@entry=1, forWrite=forWrite@entry=0, conn=conn@entry=0x1b58c50, finish_time=finish_time@entry=-1) at fe-misc.c:1003 #5 0x00007f3f4d454012 in connectDBComplete (conn=0x1b58c50) at fe-connect.c:1902 #6 PQconnectdbParams (keywords= , values= , expand_dbname= ) at fe-connect.c:542 #7 0x000000000040576a in doConnect () #8 0x0000000000406e29 in threadRun () #9 0x0000000000403a1b in main ()
3、修改系統配置,保證有足夠的fd, proc等
《PostgreSQL 10 + PostGIS + Sharding(pg_pathman) + MySQL(fdw外部表) on ECS 部署指南(適合新用戶) - 珍藏級》
4、postgresql.conf 通用配置
listen_addresses = "0.0.0.0" max_connections = 30000 superuser_reserved_connections = 13 unix_socket_directories = "/tmp,." tcp_keepalives_idle = 60 tcp_keepalives_interval = 10 tcp_keepalives_count = 0 shared_buffers = 32GB huge_pages = on maintenance_work_mem = 1GB dynamic_shared_memory_type = posix vacuum_cost_delay = 0 bgwriter_delay = 10ms bgwriter_lru_maxpages = 500 effective_io_concurrency = 0 max_parallel_workers_per_gather = 0 wal_level = minimal fsync = on synchronous_commit = on full_page_writes = on wal_buffers = 32MB checkpoint_timeout = 15min max_wal_size = 64GB min_wal_size = 16GB checkpoint_completion_target = 0.1 max_wal_senders = 0 random_page_cost = 1.2 log_destination = "csvlog" logging_collector = on log_truncate_on_rotation = on log_checkpoints = on log_connections = on log_disconnections = on log_error_verbosity = verbose log_timezone = "PRC" autovacuum = on log_autovacuum_min_duration = 0 autovacuum_freeze_max_age = 900000000 autovacuum_multixact_freeze_max_age = 900000000 autovacuum_vacuum_cost_delay = 0ms vacuum_freeze_min_age = 500000 vacuum_freeze_table_age = 1500000000 vacuum_multixact_freeze_min_age = 5000000 vacuum_multixact_freeze_table_age = 1500000000 datestyle = "iso, mdy" timezone = "PRC" lc_messages = "en_US.utf8" lc_monetary = "en_US.utf8" lc_numeric = "en_US.utf8" lc_time = "en_US.utf8" default_text_search_config = "pg_catalog.english"
5、社區版本與阿里云版本的差異配置
native
port = 1921
aliyun
port = 1999 shared_preload_libraries = "pg_concurrency_control.so" pg_concurrency_control.query_concurrency=64 pg_concurrency_control.bigquery_concurrency=64 pg_concurrency_control.transaction_concurrency=64 pg_concurrency_control.autocommit_concurrency=64
測試TPC-B
TPC-B測試SQL如下
scale=5000 set aid random(1, 100000 * :scale) set bid random(1, 1 * :scale) set tid random(1, 10 * :scale) set delta random(-5000, 5000) BEGIN; UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); END;
logged table
1、初始化
./pgsql11/bin/pgbench -i -s 5000
2、表大小
postgres=# dt+ List of relations Schema | Name | Type | Owner | Size | Description --------+------------------+-------+----------+---------+------------- public | pgbench_accounts | table | postgres | 63 GB | public | pgbench_branches | table | postgres | 216 kB | public | pgbench_history | table | postgres | 0 bytes | public | pgbench_tellers | table | postgres | 2200 kB | (4 rows)
3、社區版本測試腳本如下
vi test_native.sh #!/bin/bash export PGHOST=/tmp export PGPORT=1921 export PGUSER=postgres export PGDATABASE=postgres Y=32 for ((i=1;i<=7;i++)) do X=$((Y*2)) psql -c "vacuum freeze" psql -c "checkpoint" ./pgsql11/bin/pgbench -M prepared -n -r -P 3 -c $X -j 64 -T 300 > ./test_native_$X.log 2>&1 Y=X done psql -c "vacuum freeze" psql -c "checkpoint" ./pgsql11/bin/pgbench -M prepared -n -r -P 3 -c 8192 -j 128 -T 600 > ./test_native_8192.log 2>&1 psql -c "vacuum freeze" psql -c "checkpoint" ./pgsql11/bin/pgbench -M prepared -n -r -P 3 -c 16384 -j 256 -T 600 > ./test_native_16384.log 2>&1
測試方法
chmod 700 ./test_native.sh nohup ./test_native.sh >/dev/null 2>&1 &
5、阿里云版本測試腳本如下
vi test_aliyun.sh #!/bin/bash export PGHOST=/tmp export PGPORT=1999 export PGUSER=postgres export PGDATABASE=postgres Y=32 for ((i=1;i<=7;i++)) do X=$((Y*2)) psql -c "vacuum freeze" psql -c "checkpoint" ./pgsql11/bin/pgbench -M prepared -n -r -P 3 -c $X -j 64 -T 300 > ./test_aliyun_$X.log 2>&1 Y=X done psql -c "vacuum freeze" psql -c "checkpoint" ./pgsql11/bin/pgbench -M prepared -n -r -P 3 -c 8192 -j 128 -T 600 > ./test_aliyun_8192.log 2>&1 psql -c "vacuum freeze" psql -c "checkpoint" ./pgsql11/bin/pgbench -M prepared -n -r -P 3 -c 16384 -j 256 -T 600 > ./test_aliyun_16384.log 2>&1
測試方法
chmod 700 ./test_aliyun.sh nohup ./test_aliyun.sh >/dev/null 2>&1 & unlogged table
1、初始化
./pgsql11/bin/pgbench -i -s 5000 --unlogged-tables
2、修改數據庫配置
vi $PGDATA/postgresql.conf synchronous_commit = off pg_ctl reload
3、測試同樣的腳本
性能對比
1 logged table對比
1、TPS對比
連接數 社區版本TPS 阿里云版本TPS 社區版本TPS
(過濾首尾干擾值) 阿里云版本TPS
(過濾首尾干擾值)
64 69216 67853 無干擾 無干擾
128 69211 65712 無干擾 無干擾
256 62964 62775 無干擾 無干擾
512 44595 53382 46141 54988
1024 35055 44295 37022 48679
2048 26791 38881 30327 44358
4096 24218 26990 32023 39086
8192 7064 24304 18611 34316
16384 5046 12478 10020 29499
1.6萬并發時,約3倍于社區版本。
2、事務整體RT對比
連接數 社區版本RT 阿里云版本RT
64 0.923 ms 0.941 ms
128 1.839 ms 1.936 ms
256 4.010 ms 4.021 ms
512 11.151 ms 9.269 ms
1024 27.475 ms 21.070 ms
2048 67.295 ms 46.063 ms
4096 127.923 ms 104.689 ms
8192 999.236 ms 239.466 ms
16384 1594.185 ms 577.913 ms
3、實際SQL RT對比
連接數 社區版本RT 阿里云版本RT
64 0.428 ms 0.465 ms
128 0.698 ms 0.734 ms
256 1.784 ms 1.658 ms
512 4.736 ms 4.378 ms
1024 11.082 ms 8.664 ms
2048 37.258 ms 8.007 ms
4096 65.486 ms 7.395 ms
8192 818.411 ms 6.472 ms
16384 1183.571 ms 4.927 ms
1.6萬連接時,真實SQL響應速度約240倍于社區版本。
4、RT 標準方差對比
連接數 社區版本RT DEV 阿里云版本RT DEV
64 2.960 ms 2.863 ms
128 7.559 ms 4.914 ms
256 6.595 ms 6.090 ms
512 11.810 ms 8.704 ms
1024 30.656 ms 46.411 ms
2048 88.371 ms 68.239 ms
4096 183.815 ms 140.255 ms
8192 20114.612 ms 345.584 ms
16384 2404.222 ms 1116.238 ms
5、建立完所有連接的耗時對比
連接數 社區版本 阿里云版本
64 0 s 0 s
128 0 s 0 s
256 4.8 s 5 s
512 8.9 s 11.3 s
1024 18.5 s 27.4 s
2048 36.3 s 37.8 s
4096 73.5 s 93.6 s
8192 150.9 s 168.6 s
16384 306 s 341.8 s
6、釋放完所有連接的耗時對比
連接數 社區版本 阿里云版本
64 0 s 0 s
128 0 s 0 s
256 0 s 0 s
512 0 s 0 s
1024 0 s 0 s
2048 0 s 0 s
4096 0 s 0 s
8192 594 s 9 s
16384 21 s 24 s
2 unlogged table對比
1、TPS對比
連接數 社區版本TPS 阿里云版本TPS 社區版本TPS
(過濾首尾干擾值) 阿里云版本TPS
(過濾首尾干擾值)
64 99086 95932 無干擾 無干擾
128 86807 86719 無干擾 無干擾
256 69805 74371 70766 75143
512 49147 59423 50369 61153
1024 42295 45883 44798 48910
2048 32147 38698 36729 44552
4096 23556 27604 31504 38334
8192 17037 24524 22937 34553
16384 196 12668 1943 30273
2、事務整體RT對比
連接數 社區版本RT 阿里云版本RT
64 0.644 ms 0.666 ms
128 1.466 ms 1.466 ms
256 3.617 ms 3.391 ms
512 10.115 ms 8.343 ms
1024 22.761 ms 20.864 ms
2048 55.771 ms 45.903 ms
4096 130.195 ms 107.858 ms
8192 356.904 ms 239.312 ms
16384 66640.630 ms 570.207 ms
3、實際SQL RT對比
連接數 社區版本RT 阿里云版本RT
64 0.475 ms 0.501 ms
128 0.934 ms 0.854 ms
256 2.109 ms 1.842 ms
512 4.656 ms 4.587 ms
1024 9.837 ms 8.69 ms
2048 36.882 ms 7.928 ms
4096 67.513 ms 7.522 ms
8192 201.208 ms 6.536 ms
16384 65428.243 ms 4.811 ms
4、RT 標準方差對比
連接數 社區版本RT DEV 阿里云版本RT DEV
64 2.941 ms 1.767 ms
128 4.445 ms 2.763 ms
256 5.515 ms 2.775 ms
512 11.424 ms 4.447 ms
1024 28.950 ms 16.575 ms
2048 87.051 ms 52.400 ms
4096 200.132 ms 149.614 ms
8192 403.771 ms 358.461 ms
16384 462277.689 ms 1161.376 ms
5、建立完所有連接的耗時對比
連接數 社區版本 阿里云版本
64 0 s 0 s
128 0 s 0 s
256 4.9 s 5.3 s
512 9.4 s 10.2 s
1024 18.5 s 20.2 s
2048 37.6 s 40 s
4096 75 s 81.3 s
8192 151.6 s 168.4 s
16384 312.1 s 341.5 s
6、釋放完所有連接的耗時對比
連接數 社區版本 阿里云版本
64 0 s 0 s
128 0 s 0 s
256 0 s 0 s
512 0 s 0 s
1024 0 s 0 s
2048 0 s 0 s
4096 3 s 3 s
8192 6 s 9 s
16384 3312 s 27 s
小結
進程模型數據庫,需要為每個會話指派獨立的進程與之服務,在連接數非常多,且大都是活躍連接時,進程調度浪費或引入的開銷甚至遠遠大于實際任務需要的開銷(例如上下文切換,MEMCPY等),性能下降會較為嚴重。
阿里云RDS PG,采用與Oracle Shared Server模式類似的方案,解決了進程模式在高并發的情況下性能下降的問題。
在超過1萬個活躍并發的情況下,阿里云RDS PG的TPC-B測試指標依舊能夠保持15萬左右的QPS (消除干擾項),吞吐能力是社區版本的3倍。同時,在低并發的情況下,性能不減,與社區版本相當。
具體測試結果分析:
1、阿里云RDS PG在高并發下,TPS相比社區版本好很多,更加平穩。
2、阿里云RDS PG引入了POOL機制后,響應延遲,抖動相比社區版本低了很多。
3、啟用POOL后,整個事務的RT,相比社區版本降低,使得整個處理吞吐得到提升。
4、啟用POOL機制,使得一個事務中,真正執行SQL的時間大大縮短。同時還避免了鎖等待的問題。
16384個連接,社區版本
1.750 BEGIN; 21.531 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; 0.745 SELECT abalance FROM pgbench_accounts WHERE aid = :aid; 461.077 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; 700.583 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; 1.958 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); 408.864 END;
16384個連接,阿里云版本
559.291 BEGIN; 2.359 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; 1.223 SELECT abalance FROM pgbench_accounts WHERE aid = :aid; 1.191 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; 2.310 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; 0.981 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); 13.695 END;
對比以上兩個版本的事務BEGIN的耗費時間、SQL執行時間的分布:
社區版本的SQL執行時間耗時更高(基本達到了500毫秒左右);
阿里云的PG版本,SQL執行時間非常短(基本都在1毫秒左右)。
實際的DML SQL執行越久,持鎖就越久,并發1萬多時,社區版本PG出現較多WAITING狀態,就可以說明問題。
0:00.18 postgres: postgres postgres [local] UPDATE waiting 0:02.62 postgres: postgres postgres [local] UPDATE waiting 0:00.15 postgres: postgres postgres [local] UPDATE waiting 0:00.17 postgres: postgres postgres [local] UPDATE waiting 0:00.12 postgres: postgres postgres [local] UPDATE waiting 0:00.11 postgres: postgres postgres [local] UPDATE waiting .............................. 0:00.13 postgres: postgres postgres [local] COMMIT 0:00.13 postgres: postgres postgres [local] UPDATE waiting 0:00.13 postgres: postgres postgres [local] UPDATE waiting 0:00.16 postgres: postgres postgres [local] UPDATE waiting 0:00.14 postgres: postgres postgres [local] UPDATE waiting .....................
阿里云RDS PG內置POOL,不會導致SQL執行時間變長。因此有效的避免了持有資源鎖的問題,是的真實的SQL RT非常的平穩。
連接數 社區版本RT 阿里云版本RT
64 0.475 ms 0.501 ms
128 0.934 ms 0.854 ms
256 2.109 ms 1.842 ms
512 4.656 ms 4.587 ms
1024 9.837 ms 8.69 ms
2048 36.882 ms 7.928 ms
4096 67.513 ms 7.522 ms
8192 201.208 ms 6.536 ms
16384 65428.243 ms 4.811 ms
5、啟用POOL后,16384個連接高并發下,收尾時長縮短。從3312秒縮短到了27秒。
6、進程模式,建立連接比較耗時,如果業務上需要短時間內創建大量連接,也是一個瓶頸。比如創建16384個連接,串行創建,全部建立完16384個連接大概需要花費300秒。這樣的業務,建議采用業務層連接池,并且配置較少的后端連接。
7、pgbench在統計TPS時,從所有連接建立完成,到所有連接退出,這之間產生的TPS。當需要建立很多連接或釋放很多連接時,可能會耗時比較久,導致實際測試的性能不準,特別是在8000個連接以上時,斷開連接過程中,TPS下降比較明顯,并且會被統計進去,實測600秒,到1000多秒才完成統計,詳見LOG。
8、阿里云RDS PG內置POOL,相比外置連接池,還有一個好處是“不會影響綁定變量的使用,也不會引入新的跳數,同時不會影響數據庫pg_hba.conf防火墻的配置”。
在超過1萬個活躍并發的情況下,阿里云RDS PG的TPC-B測試指標依舊能夠保持15萬左右的QPS (消除干擾項),吞吐能力是社區版本的3倍。真實SQL執行響應速度240倍于社區版本。同時低并發的情況下,性能不減,與社區版本相當。
原文鏈接
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/17765.html
摘要:昨天寫的小企業如何選擇阿里云服務器已刪除,重新編輯了一篇之前已經在個人如何選擇阿里云服務器文章中介紹了個人購買阿里云服務器的方法,今天來說下小企業如何選擇阿里云服務器的配置。昨天寫的小企業如何選擇阿里云服務器已刪除,重新編輯了一篇之前已經在個人如何選擇阿里云服務器文章中介紹了個人購買阿里云服務器的方法,今天來說下小企業如何選擇阿里云服務器的配置。 企業和個人最大的區別就是企業面向的用戶眾多,...
摘要:今天來說下企業如何選擇阿里云服務器的配置。其中計算型一般用來做服務器,這也是阿里云官方推薦的配置。如果企業有別的特殊業務需求,則可以參考阿里云給出的各個架構的特點進行選擇。今天來說下企業如何選擇阿里云服務器的配置。 企業和個人最大的區別就是企業面向的用戶眾多,對訪問速度和數據安全性要求非常高。試想下你的網站三天兩頭被黑客攻擊,網站被黑了,數據沒了,這樣的網站怎么能吸引到用戶呢。 對于個人站長...
摘要:如果企業有別的特殊業務需求,則可以參考阿里云給出的各個架構的特點進行選擇。就是我們的數據庫,具體選擇哪項,則依賴于我們用到數據庫的版本,目前阿里云上主要具有四個版本的數據庫,分別是,,,。如今上云服務器已經成為企業和個人部署站點的首選,成本非常低,可以升降配。阿里的云市場有各種業務的解決方案。 企業和個人最大的區別就是企業面向的用戶眾多,對訪問速度和數據安全性要求非常高。試想下你的網站三天兩...
摘要:云棲大會北京峰會上,阿里云宣布啟動數據庫開源項目。日前,用戶內測邀請正式啟動。測試報告樣例阿里云關系數據庫服務內核開發和運維團隊負責人,活躍的社區貢獻者丁奇表示,在通用基準測試場景下,版本比官方版本有著的性能提升。 2016 云棲大會·北京峰會上,阿里云宣布啟動 AliSQL 數據庫開源項目。日前,用戶內測邀請正式啟動。根據阿里云數據庫團隊的規劃,今年 10 月,開發者將可以在阿里云 Cod...
閱讀 1039·2021-09-13 10:29
閱讀 3390·2019-08-29 18:31
閱讀 2633·2019-08-29 11:15
閱讀 3012·2019-08-26 13:25
閱讀 1369·2019-08-26 12:00
閱讀 2293·2019-08-26 11:41
閱讀 3377·2019-08-26 10:31
閱讀 1488·2019-08-26 10:25