Postgres-XL 调优

Postgresql-xl 节点介绍

转载： (19条消息) Postgresql-xl 结构_有梦为马 随处可栖-CSDN博客_postgresql xl

GTM

全局事务控制节点，保证集群数据一致性，与coordinator节点和datanode节点不断通信，是整个集群的核心节点，只存在一个，可以存在一个GTM standby节点，对GTM实时备份。GTM一旦故障，整个集群立刻无法访问，此时可以切换到GTM standby节点上。如果部署了GTM standby节点，就应该同时部署GTM proxy，一般和coordinator datanode部署在同一台服务器上。GTM proxy的作用，代理coordinator datanode对GTM的访问，起到减轻GTM负载的作用，另外一个重要的作用是帮助完成GTM的故障切换，当GTM发生故障后，GTM standby成为新的GTM，此时coordinator datanode节点并不需要重新指定GTM地址，只需要GTM Proxy重新连接到新的GTM地址即可。

Coordinator

接收数据访问请求的节点，本质上是由PG后台进程组成。接收的一条查询后，coordinator节点执行查询计划，然后会根据查询数据涉及的数据节点将查询分发给相关的数据节点。写入数据时，也会根据不同的数据分布策略将数据写入相关的节点。可以说coordinator节点上保存着集群的全局数据位置，coordinator节点可以任意扩展，各个节点之间除了访问地址不同以外是完全对等的，通过一个节点更新的数据可以在另一个节点上立刻看到。每个coordinator节点可以配置一个对应的standby节点，避免单点故障。

Datanode

实际存取数据的节点，接收coordinator的请求并执行SQL语句存取数据，节点之间也会互相通信。一般的，一个节点上的数据并不是全局的，数据节点不直接对外提供数据访问。一个表的数据在数据节点上的分布存在两种模式：复制模式和分片模式：复制模式下，一个表的数据在指定节点上存在多个副本；分片模式下，一个表的数据按照一定的规则分布在多个数据节点上，这些节点共同保存一份完整的数据。

Postgresql-xl 调优

1. 排查Coordinator 的上游，是否能发出高traffic，比如，检查上游heplify server 的 goroutione数量等。

2. 排查 Coordinator 的上游 和 pg-xl 的 TCP 跑道是否足够宽

    1> 在 cr 上抓包，看是否有存在，TCP window size 为 0 和 TCP retransmission 的情况

    2> 根据需要，调整 TCP IPV4 setting 保证 有足够的 receive send buffer 为每一个TCP socket

          net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_mem

3. 查看 pg-xl 的瓶颈在哪里？

写速率： 1.6G/Min 

    1> 查看在创建表时，是否可以删除一些不必要的索引（index）

     2> pg-xl  配置参数的调优

          process numbers， Memory， IO-WAL, IO-Checkpointer， Two-phase Commit

    3> 查看 Lock 等待状态

         "select * from pg_stat_activities" 查看是否有些进程被stuck 由于等待锁

         解决方案： 更改了 分布式方案 DISTRIBUTE BY ROUNDROBIN => DISTRIBUTE BY MODUBO(tag)

     4> 查看IO 性能

          现象，使用glusterfs 作为永久存储，发现 cpu 消耗越来越大，怀疑IO是瓶颈。

          验证方法， 去掉永久存储，做比较实验，发现性能大大提高。

          了解到glusterfs 性能远差于Cinder performance，解决方案，换成Cinder 存储。

总结： 对性能影响的关键因素

1> IO

2> DB Lock

3> Networking

4> DB memory

后来，把透明大页也打开了。