Postgres-XL和PostgreSQL性能对比测试

  为了测量coordinate和datanode对PostgreSQL-XL查询性能的影响，所以尽可能的排除掉其他因素的干扰，所以测试环境为：
  对于PostgreSQL-XL，其客户端、gtm、ctm_proxy、coordinate和datanode都在一个节点上，且coordinate和datanode都只有一个节点，在Coordinator的配置文件PostgreSQL.conf中增加：global_snapshot_source = ‘coordinator’配置。
  对于做对比的PostgreSQL，客户端和PostgreSQL都在一个节点上。

1.1 通过perf stat 判断是否属于CPU bound 型

  因为有些程序慢是因为计算量太大，其多数时间都应该在使用 CPU 进行计算，这叫做 CPU bound 型；有些程序慢是因为过多的 IO，这种时候其 CPU 利用率应该不高，这叫做 IO bound 型；对于 CPU bound 程序的调优和 IO bound 的调优是不同的。

• 1、对coordinate和datanode分别采用perf stat，得到的结果如下所示：

  如下图所示，coordinate的task-clock (msec)占用率达到0.41，说明程序的多数时间花费在 CPU 计算上而非 IO；

  如下图所示，datanode的task-clock (msec)占用率为0.296，说明程序的花费在 CPU 计算上和 IO上差不多；

1.2 对做对比的PostgreSQL环境采用perf stat分析

  可以看出其task-clock (msec)占用率达到0.539，说明程序的多数时间花费在 CPU 计算上而非 IO；而且cpu利用率也高于coordinate和datanode；

1.3 采用pgbench进行性能测试

• 1、首先采用pgbench在pgxl和postgres环境上分别生成2千万测试数据：

pgbench -i -F 100 -s 200 -h 192.168.80.230 -U pgxl -d mydb2 -p 5432

• 2、分别在pgxl和postgres环境测试2并发时数据库性能，测试数据300秒：

nohup pgbench -M prepared -n -r -P 1 -c 2 -j 2  -T 300 -d mydb2 -U pgxl -h 192.168.80.230 -p 5432 -f test.sql >bench2.log  2>&1 &

其中test.sql是：

\set naccounts 100000 * :scale
\setrandom aid 1 :naccounts
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;

1.3.1 Postgres-XL和PostgreSQL压力测试的tps对比

在Postgres-XL上得到的结果如下，可以看到简单查询的tps只有9213：

  作为对比的PostgreSQL环境上同样的测试场景，得到的tps为18714，比Postgres-XL多了一倍，结果如下图所示：

1.3.2 Postgres-XL和PostgreSQL压力测试的CPU对比

  Postgres-XL上coordinate进程fork出的两个子进程（因为有两个客户端）所耗cpu分别为：40.7%和40.1%，而datanode进程fork出的两个子进程所耗cpu分别为：30.1%和29.5%，如下所示：

  PostgreSQL进程fork出的两个子进程所耗cpu分别为：54.6%和54.0%，如下所示：

1.3.3 Postgres-XL和PostgreSQL压力测试的perf record结果对比

  采用“perf record -e cpu-clock -g –p ”分别统计PostgreSQL-XL的coordinate和datanode进程fork出的一个子进程，以及作为对比的postgres进程fork出的一个子进程，然后采用“perf report -g”命令查看统计结果如下：
  coordinate进程fork出的一个子进程，通过“perf report -g”命令得到的性能数据如下，即在进行压力查询测试过程中所调用的函数所花时间占这个测试周期时间比：

  从上图可以看出，在进行压力查询测试过程中所调用的函数所花时间比，基本上都在1%以内，没有哪个函数本身耗时较多；
  下图为某个函数调用的子函数所占整个程序运行时间的百分比，从PostgresMain函数往下依次查看：

  datanode进程fork出的一个子进程，通过“perf report -g”命令得到的性能数据如下

  作为对比的postgres进程fork出的一个子进程，通过“perf report -g”命令得到的性能数据如下图所示：

1.3.4 总结

  注：上表中蓝色表明的函数为查询流程的几大关键函数，后面的黑色字体的函数为其调用的子函数；

从上表可以看出：

• 1、相比作为对比的PostgreSQL进程，Postgres-XL的coordinate和datanode的CPU占用率都要小，没有将性能发挥出来，其原因很可能是coordinate依赖datanode获取数据，而造成等待；

• 2、同样的测试用例，Postgres-XL的tps要比postgres小一倍；

• 3、通过perf record的结果可以看出，在查询压力测试过程中coordinate所调用函数大部分和PostgreSQL一样，时间占用比也差不多；
  不同点在exec_bind_message和exec_execute_message函数，因为对于简单查询，coordinate对其进行语义解析（parse*tring函数）后直接将查询语句通过pgxc_node_send_flush函数发给datanode去执行，所以只有datanode才会调用ExecInitIndexScan（初始化索引扫描的状态信息）和index_getnext_tid（获取下一个TID）；
  也正是因为coordinate依赖于datanode去执行查询计划，并且将查询结果通过internal_flush函数（调用socket的send）发送给coordinate，这样导致coordinate会暂时阻塞，直到datanode返回查询结果，才会进行后续流程，从而影响pgxl的查询性能。