PgSQL · 应用案例 · 阿里云 RDS PostgreSQL 高并发特性 vs 社区版本

摘要： 背景 进程模型数据库，需要为每个会话指派独立的进程与之服务，在连接数非常多，且大都是活跃连接时，进程调度浪费或引入的开销甚至远远大于实际任务需要的开销（例如上下文切换，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。在高并发的情况下，性能好很多。测试CASE1、测试64 ~ 16384个并发2、测试TPC-B，包含5亿数据量。3、测试logged table与unlogged table4、测试对比社区PostgreSQL 10 与 阿里云PostgreSQL 10测试环境准备1、数据库使用huge page《PostgreSQL Huge Page 使用建议 - 大内存主机、实例注意》2、修改pgbench，支持超过1000个连接的测试《PostgreSQL 11 preview - pgbench 支持大于1000链接(ppoll()代替select())》https://commitfest.postgresql.org/18/1388/《从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、社区版本与阿里云版本的差异配置
nativeport = 1921   
aliyunport = 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-BTPC-B测试SQL如下scale=5000set 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 table1、初始化./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 table1、初始化./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
(过滤首尾干扰值)
646921667853无干扰无干扰
1286921165712无干扰无干扰
2566296462775无干扰无干扰
51244595533824614154988
102435055442953702248679
204826791388813032744358
409624218269903202339086
81927064243041861134316
1638450461247810020294991.6万并发时，约3倍于社区版本。2、事务整体RT对比连接数社区版本RT阿里云版本RT
640.923 ms0.941 ms
1281.839 ms1.936 ms
2564.010 ms4.021 ms
51211.151 ms9.269 ms
102427.475 ms21.070 ms
204867.295 ms46.063 ms
4096127.923 ms104.689 ms
8192999.236 ms239.466 ms
163841594.185 ms577.913 ms3、实际SQL RT对比连接数社区版本RT阿里云版本RT
640.428 ms0.465 ms
1280.698 ms0.734 ms
2561.784 ms1.658 ms
5124.736 ms4.378 ms
102411.082 ms8.664 ms
204837.258 ms8.007 ms
409665.486 ms7.395 ms
8192818.411 ms6.472 ms
163841183.571 ms4.927 ms1.6万连接时，真实SQL响应速度约240倍于社区版本。4、RT 标准方差对比连接数社区版本RT DEV阿里云版本RT DEV
642.960 ms2.863 ms
1287.559 ms4.914 ms
2566.595 ms6.090 ms
51211.810 ms8.704 ms
102430.656 ms46.411 ms
204888.371 ms68.239 ms
4096183.815 ms140.255 ms
819220114.612 ms345.584 ms
163842404.222 ms1116.238 ms5、建立完所有连接的耗时对比连接数社区版本阿里云版本
640 s0 s
1280 s0 s
2564.8 s5 s
5128.9 s11.3 s
102418.5 s27.4 s
204836.3 s37.8 s
409673.5 s93.6 s
8192150.9 s168.6 s
16384306 s341.8 s6、释放完所有连接的耗时对比连接数社区版本阿里云版本
640 s0 s
1280 s0 s
2560 s0 s
5120 s0 s
10240 s0 s
20480 s0 s
40960 s0 s
8192594 s9 s
1638421 s24 s2 unlogged table对比1、TPS对比连接数社区版本TPS阿里云版本TPS社区版本TPS
(过滤首尾干扰值)阿里云版本TPS
(过滤首尾干扰值)
649908695932无干扰无干扰
1288680786719无干扰无干扰
25669805743717076675143
51249147594235036961153
102442295458834479848910
204832147386983672944552
409623556276043150438334
819217037245242293734553
16384196126681943302732、事务整体RT对比连接数社区版本RT阿里云版本RT
640.644 ms0.666 ms
1281.466 ms1.466 ms
2563.617 ms3.391 ms
51210.115 ms8.343 ms
102422.761 ms20.864 ms
204855.771 ms45.903 ms
4096130.195 ms107.858 ms
8192356.904 ms239.312 ms
1638466640.630 ms570.207 ms3、实际SQL RT对比连接数社区版本RT阿里云版本RT
640.475 ms0.501 ms
1280.934 ms0.854 ms
2562.109 ms1.842 ms
5124.656 ms4.587 ms
10249.837 ms8.69 ms
204836.882 ms7.928 ms
409667.513 ms7.522 ms
8192201.208 ms6.536 ms
1638465428.243 ms4.811 ms4、RT 标准方差对比连接数社区版本RT DEV阿里云版本RT DEV
642.941 ms1.767 ms
1284.445 ms2.763 ms
2565.515 ms2.775 ms
51211.424 ms4.447 ms
102428.950 ms16.575 ms
204887.051 ms52.400 ms
4096200.132 ms149.614 ms
8192403.771 ms358.461 ms
16384462277.689 ms1161.376 ms5、建立完所有连接的耗时对比连接数社区版本阿里云版本
640 s0 s
1280 s0 s
2564.9 s5.3 s
5129.4 s10.2 s
102418.5 s20.2 s
204837.6 s40 s
409675 s81.3 s
8192151.6 s168.4 s
16384312.1 s341.5 s6、释放完所有连接的耗时对比连接数社区版本阿里云版本
640 s0 s
1280 s0 s
2560 s0 s
5120 s0 s
10240 s0 s
20480 s0 s
40963 s3 s
81926 s9 s
163843312 s27 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
640.475 ms0.501 ms
1280.934 ms0.854 ms
2562.109 ms1.842 ms
5124.656 ms4.587 ms
10249.837 ms8.69 ms
204836.882 ms7.928 ms
409667.513 ms7.522 ms
8192201.208 ms6.536 ms
1638465428.243 ms4.811 ms5、启用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倍于社区版本。同时低并发的情况下，性能不减，与社区版本相当。原文链接