Postgres-x2是一个基于pgsql、面向OTLP的分布式数据库,采用了shared-nothing的架构,目标是针对OLTP\OLAP应用能做到可扩展的系统。源码在github上:https://github.com/postgres-x2/postgres-x2 。
最近在针对 Postgres-x2做压力测试。测试是在一台DEll R510上进行的,该服务器上有4颗X5650和64G内存,另外是两块老式的SSD,型号不详,最大写入速度100M左右。
测试的版本是直接从github上拉下来的,直接编译安装。在这台服务器上安装了GTM、coordinator、datanode各一个,GTM和coordinator的数据目录都在一个SSD上,datanode的数据目录在另外的一个SSD盘上。以最大化利用磁盘资源。之所以在一台服务器上进行测试,主要是想模拟一个网络带宽不受限的环境,也是为了简化问题。
coordinator的几个重要配置如下:
max_connections = 1024 shared_buffers = 2048MB # shared_buffer没有必要设置过大 checkpoint_segments = 64 checkpoint_timeout = 20min # 让checkpoint间隔尽量大 logging_collector = on autovacuum = off min_pool_size = 100 # 连接池初始大小 max_pool_size = 1024
datanode的配置如下
max_connections = 1024 shared_buffers = 20480MB vacuum_cost_delay = 10 vacuum_cost_limit = 10000 checkpoint_segments = 256 checkpoint_timeout = 10min logging_collector = on autovacuum_vacuum_cost_delay = 5ms
测试的主要方法是使用pgbench生成scale为1000的数据集合,大概有16G,主要的测试方法就是先执行checkpoint,将数据块刷回磁盘,以减小checkpoint的影响,然后执行下面的命令:
pgbench -c N -j N -T 60
N是连接数,这个操作会模拟并发的N个客户连续访问数据库60秒,每个客户需要在60秒内不停执行一个有着5条SQL的事务:
BEGIN; UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2; UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2; SELECT abalance FROM pgbench_accounts WHERE aid = $1; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES ($1, $2, $3, $4, CURRENT_TIMESTAMP); UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2; END;
测试的时候,N从32增大到768,取TPS。结果如下:
随着连接数的增加,TPS几乎是线性降低。datanode数据目录所在的磁盘使用率也基本上从最高的60%降低到了20%,而整体的CPU使用率不怎么飙升,只是GTM看起来还比较忙。
感觉GTM比较有问题,于是祭出了gprof来做性能分析,结果啥都没有,google一下,发现是gtm屏蔽了SIGPROF信号,打上我的这个patch就OK了:
diff --git a/src/gtm/libpq/pqsignal.c b/src/gtm/libpq/pqsignal.c index e3f482c..594540f 100644 --- a/src/gtm/libpq/pqsignal.c +++ b/src/gtm/libpq/pqsignal.c @@ -119,6 +119,10 @@ pqinitmask(void) sigdelset(&BlockSig, SIGCONT); sigdelset(&AuthBlockSig, SIGCONT); #endif +#ifdef SIGPROF + sigdelset(&BlockSig, SIGPROF); + sigdelset(&AuthBlockSig, SIGPROF); +#endif
记得使用--enable-profiling选项来重新生成makefile 或是直接编辑makefile加上 -pg选项,然后重新编译一下gtm。拿pgbench运行一段时间之后,停掉gtm,在gtm的目录下会有一个gmon.out,执行:
gprof -b /usr/local/pgx2/bin/gtm gmon.out > gtm.out
在生成的gtm.out中,可以看到有两个函数几乎占用了CPU的大部分时间:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 31.41 49.90 49.90 8256962 0.01 0.01 GTM_GXIDToHandle 15.00 73.72 23.82 3791614 0.01 0.01 GTM_GetTransactionSnapshot 6.33 83.77 10.05 4305476 0.00 0.00 gtm_list_delete 5.07 91.83 8.06 790 10.20 181.29 GTM_ThreadMain 3.09 96.75 4.92 25006706 0.00 0.00 AllocSetAlloc 2.06 100.02 3.27 752039341 0.00 0.00 GlobalTransactionIdPrecedes 1.78 102.85 2.83 30641196 0.00 0.00 elog_start 1.66 105.49 2.64 11157165 0.00 0.00 pq_recvbuf 1.62 108.07 2.58 13648719 0.00 0.00 internal_flush
在花了半天看了这两个耗时的函数,大概有点眉目:
1,当coordinator上启动一个事务时,回去gtm申请一个一个事务id (XID) 和存放事务相关信息的GTM_TransactionInfo数据结构,并把这个数据结构的指针放入一个全局的链表GTMTransactions.gt_open_transactions中,gtm将事务ID返回给coordinator
2,事务执行时,会将XID发给gtm去获取快照。gtm会首先调用GTM_GXIDToHandle函数去获得对应的GTM_TransactionInfo数据结构的指针,GTM_GXIDToHandle函数会遍历全局链表GTMTransactions.gt_open_transactions来获取。然后将该GTM_TransactionInfo数据结构的指针传给GTM_GetTransactionSnapshot函数来获得快照:遍历GTMTransactions.gt_open_transactions中的每个元素,获取全局最小的xmin,和活跃的事务ID(小于最近提交事务的最大ID),放入快照并返回给coordinator。
3,事务结束时,coordinator将XID返回给gtm,gtm根据XID查找对应的GTM_TransactionInfo数据结构,将其回收,并删除GTMTransactions.gt_open_transactions中的对应item。
简单看来,这两个耗时的函数都是O(N)级别的复杂度,N 是GTMTransactions.gt_open_transactions的长度,也就是当前正在进行的事务数。因此,随着连接数的增加,coordinator和datanode内部锁竞争的加剧,会导致事务逐渐的积压起来,让GTMTransactions.gt_open_transactions长度变得越来越长,因此堵住了很多获取事务快照的事务。最终就是刚才描述的情形:事务等待GTM,磁盘使用率急剧降低。
所以,从直觉出发,其实可以直接用开放式hash表来优化GTM_GXIDToHandle函数,key是事务ID,value是对应的GTM_TransactionInfo的指针,将这个的函数的操作复杂度降低到O(1)。但是,发现效果并不好:因为GTM_GetTransactionSnapshot函数依然还是要去遍历所有的当前事务获取最小事务xmin和快照。
在经过一个礼拜的调整之后,直接采用教科书的方法:使用一个AVL树来存储GTM_TransactionInfo的指针,比较大小的方法就是对比其中的GXID;另外一个使用AVL树来存最小的xmin。简单来说就是分别以xmin和事务ID为主键建立两个类似BTree的索引,以满足查找需求。最终去掉了GTMTransactions.gt_open_transactions,将这两个耗时的函数的复杂度降低到了O(log(N)),N是当前系统内的事务。
采用前面的测试方法,来获取TPS。和前面的对比图如下:
可以看到优化之后的GTM响应时间基本维持在O(log(N)),从而使得TPS在连接数增大时,TPS没有像当前版本下降得这么剧烈(678个连接时,TPS是当前版本的几乎5倍),datanode的数据目录所在磁盘利用利用率机会基本维持在65%~60%之间。这样看来,基本上能改善GTM的扩展能力。
当然,这个优化并非是完美的,因为在执行简单事务并且连接数不多的情况下,TPS和原有的版本几乎相同,但是,一旦事务变得复杂,在GTM中停留的时间增大,或是连接数增大后同时执行的事务数量多了之后,优化之后的GTM相对现有的GTM会稳定很多。
最后,为了验证工作,选了三台相同配置的R510,配置和前面所述相同。一台上装GTM,其他两台上配置了coordinator和datanode各一个(配置也和前面相同)。
生成了scale为1000的数据,32G,使用前面的测试方法,但是分别执行在一张大表上的简单主键查询:
\setrandom aid 1 :1000 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
和基于主键的更新
\setrandom aid 1 10000000 \setrandom delta -5000 5000 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
在两台coordinator同时上执行。
最终, 简单select操作的总QPS最大值是45000(每个coordinator上的QPS是22500),简单update操作的总 TPS最大值是 35000(每个coordinator上最大的QPS是17500)。碰巧的是获得最大值时,每台coordinator上执行pgbench的连接数都是64。而随着连接数增大到一定程度,优化之后的GTM会比当前的GTM 结果高50%以上。
从测试看来,在64个连接数的情况,增大一个服务器(部署上datanode和coordinator),可以增加17500的TPS,网络流量增加20MB/s。因此如果真的想达到10W的TPS,预计需要10台左右这样的服务器用来部署coordinator和datanode。
但是我们需要解决两个问题:一方面,我们需要子网的交换机来提供200MB/s以上的带宽连接各个服务器,这是首先必须解决的问题,当然也是比较容易解决的问题;另外一方面,对于GTM来说,我们必须采用类似的优化来增大GTM的可扩展能力,因为如果每个coordinator上使用64个连接,那么对于10台的集群来说,系统内操作的连接数就是640了,如果还采用目前的GTM,TPS QPS会急剧下降,这是根本没法做到的。
相关推荐
- **Postgres-X2 在 MPP 方面的优化**: - **并行查询 (Parallel Query)**:利用多个数据节点并行执行查询,显著提高查询效率。 - **条件下推 (Where Pushdown)**:将 WHERE 子句的过滤条件直接下推到数据节点执行...
Postgres-X2的架构包含GTM(全局事务管理器)、GTM Proxy、协调节点(Coordinator)和数据节点(Datanode),这些组件协同工作,保证事务的一致性和系统的稳定性。 2. 分析型数据库(OLAP - On-Line Analytical ...
资源内项目源码是来自个人的毕业设计,代码都测试ok,包含源码、数据集、可视化页面和部署说明,可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,毕设答辩评审绝对信服的保底85分以上,放心下载使用,拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件,仅供学习参考, 切勿用于商业用途。
《基于YOLOv8的智慧社区独居老人生命体征监测系统》(包含源码、可视化界面、完整数据集、部署教程)简单部署即可运行。功能完善、操作简单,适合毕设或课程设计
Android Studio Meerkat 2024.3.1 Patch 1(android-studio-2024.3.1.14-mac.dmg)适用于macOS Intel系统,文件使用360压缩软件分割成两个压缩包,必须一起下载使用: part1: https://download.csdn.net/download/weixin_43800734/90557060 part2: https://download.csdn.net/download/weixin_43800734/90557056
侧轴承杯加工工艺编制及夹具设计.zip
NASA数据集锂电池容量特征提取(Matlab完整源码和数据) 作者介绍:机器学习之心,博客专家认证,机器学习领域创作者,2023博客之星TOP50,主做机器学习和深度学习时序、回归、分类、聚类和降维等程序设计和案例分析,文章底部有博主联系方式。从事Matlab、Python算法仿真工作8年,更多仿真源码、数据集定制私信。
板料折弯机液压系统设计.zip
C6150车床的设计.zip
机器学习之KNN实现手写数字
python爬虫;智能切换策略,反爬检测机制
mpls-vpn-optionA-all
56tgyhujikolp[
GB 6442-86企业职工伤亡事故调查分析规则.pdf
汽车液压式主动悬架系统的设计().zip
2000-2024年各省专利侵权案件结案数数据 1、时间:2000-2024年 2、来源:国家知识产权J 3、指标:专利侵权案件结案数 4、范围:31省 5、用途:可用于衡量知识产权保护水平
资源内项目源码是来自个人的毕业设计,代码都测试ok,包含源码、数据集、可视化页面和部署说明,可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,毕设答辩评审绝对信服的保底85分以上,放心下载使用,拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件,仅供学习参考, 切勿用于商业用途。
内容概要:本文档详细复现了金融数学课程作业,涵盖欧式看涨期权定价和投资组合优化两大部分。对于欧式看涨期权定价,分别采用Black-Scholes模型和蒙特卡洛方法进行了计算,并对彩虹期权进行了基于最大值的看涨期权定价。投资组合优化部分则探讨了最小方差组合、给定收益的最小方差组合、最大效用组合以及给定风险的最大收益组合四种情形,还对比了拉格朗日乘数法和二次规划求解器两种方法。文中不仅提供了详细的MATLAB代码,还有详尽的中文解释,确保每一步骤清晰明了。 适合人群:金融工程专业学生、量化分析师、金融数学爱好者。 使用场景及目标:①帮助学生理解和掌握金融衍生品定价的基本原理和方法;②为从事量化分析的专业人士提供实用工具和技术支持;③作为教学材料辅助高校教师讲授相关内容。 其他说明:文档还包括了完整的论文结构建议,从封面页到结论,再到附录,涵盖了所有必要元素,确保提交的作业符合学术规范。此外,还特别强调了数据预处理步骤,确保代码可以顺利运行。
脉冲电解射流加工喷射装置设计(1)
ThinkPad S1 (2nd Generation) 和ThinkPad Yoga 260 用户指南V3.0,包含如何拆机更换硬件