为什么说GTM是所有PGXC架构分布式数据库无法逾越的性能瓶颈？

PGXC

熟悉pg的人对pgxc都不陌生，pgxc最初由stromdb公司开发，应用于商业，后来被TransLattice收购并将其开源，也就是现在的pgxl。Pgxc是基于pg的非常成熟的分布式架构，是一款混合负载的htap数据库。国内也有很多基于pgxc来做的分布式数据库，例如华为GaussDB-A，腾讯Tbase，亚信antdb等或多或少都借鉴了pgxc的架构理念。pgxc的总体架构大家都很清晰了，不再赘述。

GTM

Gtm的作用一句话概括就是：为了保证数据的全局读一致性。这里有个误区，可能有人认为如果没有gtm就会造成节点间数据不一致，这种说法是错误的，gtm是为了保证某一时刻读到一致的数据，而写一致性是通过两阶段提交保证的。

 

从上面的图可以看到GTM主要与协调节点进行交互，协调节点开启一个事务首先需要去gtm取全局事务号和事务快照信息，GTM成为整个架构的瓶颈有多方面原因，这也和与cn间的交互有很大关系，下面我们再分析一下有哪几方面原因。

01

网络收发包瓶颈

我们在压力测试中发现一个比较奇怪的现象，集群中gtm主节点所在服务器cpu很高，但是其他cn、dn所在服务器cpu并不高，这样基本定位集群瓶颈在gtm。再进一步分析，gtm服务器的网络流量明显比其他服务器高，我们开发了一个脚本抓取每10s的网络包数，发现网络包数相比dn服务器高出很多，同时随着我们压力程序的并发数的增加，gtm服务器网络包数也在不断增加，但是增长的趋势是趋于平缓，最终在大概180并发时，gtm的网卡流量包数不再上涨，tps也达到最大值，继续增加并发，tps不再增长。Cpu高的一个原因是这么多流量包已经到达cpu的处理瓶颈。

 

我们看到这么多流量包其实是因为任何一个事务的开启cn都需要去gtm取事务号和快照，常高并发会造成短时间内cn到gtm的请求激增，网络流量突增，那有人可能有疑问，cn和gtm交互，为什么cn的网络没有瓶颈？因为集群中cn不止一个，cn的数目在部署时可以根据业务并发数进行调整，并且流量会通过lvs或者f5负载均衡到每个cn，所以cn和gtm是多对一的关系，所有cn的请求一股脑发到gtm，造成gtm的处理瓶颈。

 

针对网络收发包瓶颈，其实有几方面可以改进。

 

首先在产品设计方面，可以考虑将全局事务和本地事务进行区分，事务开启时先判断事务是否是全局事务，如果是本地事务则直接下发dn，不经过gtm，因为真实业务场景，可能80%以上都是本地事务。

 

另外在使用上，可以考虑将网卡由主备绑定模式改为负载均衡模式，并且进行cpu网卡的绑定，也是有一定的效果。

02

GTM组件处理上的瓶颈

这个其实和上面是有关联的，根因是由于高并发造成的gxid事务号分配的瓶颈，这个和架构其实也有一定关系。通常生产系统中gtm不会只有一个，一定有至少一个备机，而且为了保证事务号不丢失，主备要同步当前事务号信息。我们在进行高并发测试时，观察gtm的日志，发现日志刷的非常快，内容都是主备同步xxx事务号成功。所以在高并发下，gtm组件已经分配不过来那么多的事务号，处理不了那么多请求，而且主备事务号的强一致同步也对gtm处理能力造成一定的限制。

 

针对这个问题，一方面可以考虑引入第三方存储来保存事务号，例如etcd集群，将gtm分配的事务号保存在etcd中，etcd本身是高可用，强一致的集群，这样将主备同步的问题交给了etcd集群去处理事务号数据一致的问题。

 

另一方面在分配事务号的速度上，可以考虑将事务号改为批量分配，一次分配多个事务号，并且进行缓存，当事务号用尽后gtm再进行分配。

03

PG自身快照原理的限制

我们知道postgresql通过快照（snapshot）来实现MVCC与事务可见性判断。对于read commit隔离级别，要求每个事务中的查询仅能看到在该事务启动前已经提交的更改，以及当前事务中该查询之前所做的更改，这都要通过快照来实现。

 

在pg中可以通过txid_current_snapshot来显示当前的快照snapshot，快照的文本表示是’xmin:xmax:xip_list’，xmin代表最早的仍然活跃的事务的txid。所有早于xmin的事务都将已经提交并且可见，或者回滚并且死亡。xmax代表第一个尚未分配的txid，所有大于或等于xmax的txid在快照生成时尚未启动，因此不可见。xip_list表示活跃的快照事务txid列表。该列表仅包括xmin和xmax之间的活动txid。

 

下图是一个快照的图例：

 

a：’100:100:’
由于xmin为100，xid＜100的事务不活跃，xid≥100的事务活跃，当前没有活跃事务。

b：’100:104:100,102’

xid＜100的事务不活跃，xid≥100的事务活跃，100和102号事务当前活跃，101,103号事务不活跃。

 

快照最重要的作用是用于在并发事务下的元组可见性判断，我们知道pg的每条元组（tuple）头信息中也会记录事务的xmin和xmax信息，pg会根据元组的xmin、xmax与事务管理器中取得的快照信息进行一系列规则的判断，得到该元组是否对事务可见。元组可见性检查规则是非常复杂的一块内容，而且针对不同的隔离级别规则也不相同，也可以理解pg通过这些规则实现了不同的隔离级别。这块内容不再赘述。

 

再回到刚才的问题，快照为什么会成为gtm的瓶颈呢？原因在于xip_list，试想在非常高的并发下，活跃的事务列表将特别长，pg中一个事务号是32位的，当然有些分布式数据库已经改成64位了，如果有100个活跃事务会造成快照xip_list很长，同时这么多事务，每个事务都去取这么长的快照，在并发越高的时候会造成恶性循环，并发越多，活跃的事务越多，xip_list也越长，这么多的活跃事务都需要取含有很长活跃事务列表的快照信息，会很快造成瓶颈。

I Love PG
关于我们
中国开源软件推进联盟PostgreSQL分会（简称：PG分会）于2017年成立，由国内多家PG生态企业所共同发起，业务上接受工信部产业发展研究院指导。PG分会致力于构建PG产业生态，推动PG产学研用发展，是国内一家PG行业协会组织。


欢迎投稿
做你的舞台，show出自己的才华 。
投稿邮箱：partner@postgresqlchina.com
                               
                                 ——愿能安放你不羁的灵魂

技术文章精彩回顾




PostgreSQL学习的九层宝塔
PostgreSQL职业发展与学习攻略
搞懂PostgreSQL数据库透明数据加密之加密算法介绍
一文读懂PostgreSQL-12分区表
PostgreSQL源码学习之：RegularLock
Postgresql源码学习之词法和语法分析
PostgreSQL buffer管理
最佳实践—PG数据库系统表空间重建
PostgreSQL V12中的流复制配置
2019，年度数据库舍 PostgreSQL 其谁?
PostgreSQL使用分片（sharding）实现水平可扩展性
一文搞懂PostgreSQL物化视图
PostgreSQL原理解析之：PostgreSQL备机是否做checkpoint
PostgreSQL复制技术概述

PG活动精彩回顾




见证精彩|PostgresConf.CN2019大会盛大开幕
PostgresConf.CN2019大会DAY2|三大分论坛，精彩不断
PostgresConf.CN2019培训日|爆满！Training Day现场速递！
「PCC-Training Day」培训日Day2圆满结束，PCC2019完美收官
创建PG全球生态！PostgresConf.CN2019大会盛大召开
首站起航！2019“让PG‘象’前行”上海站成功举行
走进蓉城丨2019“让PG‘象’前行”成都站成功举行
中国PG象牙塔计划发布，首批合作高校授牌仪式在天津举行
PostgreSQL实训基地落户沈阳航空航天大学和渤海大学，高校数据库课改正当时
群英论道聚北京，共话PostgreSQL
相聚巴厘岛| PG Conf.Asia 2019  DAY0、DAY1简报
相知巴厘岛| PG Conf.Asia 2019 DAY2简报
相惜巴厘岛| PG Conf.Asia 2019 DAY3简报
独家|硅谷Postgres大会简报
全球规模最大的PostgreSQL会议等你来！

PG培训认证精彩回顾




关于中国PostgreSQL培训认证，你想知道的都在这里！
首批中国PGCA培训圆满结束，首批认证考试将于10月18日和20日举行！
中国首批PGCA认证考试圆满结束，203位考生成功获得认证！
中国第二批PGCA认证考试圆满结束，115位考生喜获认证！
请查收：中国首批PGCA证书！
重要通知：三方共建，中国PostgreSQL认证权威升级！
一场考试迎新年 | 12月28日，首次PGCE中级认证考试开考！
近500人参与！首次PGCE中级、第三批次PGCA初级认证考试落幕！