PostgreSQL 单机多实例on XFS 润滑性测试

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介:

背景

前面一篇将EXT4 单机多实例在使用cgroup限制IOPS时,出现了IO HANG, 即使使用了data=writeback问题依旧。

从D状态的进程打印的PSTACK可以看到,问题卡在ext4上面。

详见 《PostgreSQL 9.6 检查点SYNC_FILE_RANGE 在单机多实例下的IO Hang问题浅析与优化》

阿里云的RDS PostgreSQL通过优化检查点调度解决了这个问题,原理也可以参考上文。

XFS是一个非常不错的文件系统,特别是在高并发的场景下面,性能比EXT4要好。

我之前在测试PostgreSQL 9.6的并行计算时,也能体现出XFS更优的一面。

本文将给大家展示XFS在PG单机多实例的场景,表现如何。

test cast请参考 《PostgreSQL 主机性能测试方法 - 单机多实例》

XFS 单机多实例测试

逻辑卷

parted -s /dev/dfa mklabel gpt
parted -s /dev/dfb mklabel gpt
parted -s /dev/dfa mkpart primary 1MiB 6400GB
parted -s /dev/dfb mkpart primary 1MiB 6400GB
pvcreate /dev/df[ab]1
vgcreate -s 128M vgdata01 /dev/df[ab]1
lvcreate -i 2 -I 8 -n lv01 -L 2GiB vgdata01
lvcreate -i 2 -I 8 -n lv02 -L 2GiB vgdata01
lvcreate -i 2 -I 8 -n lv03 -L 4TiB vgdata01
lvcreate -i 2 -I 8 -n lv04 -l 100%FREE vgdata01

设备号

#dmsetup ls
vgdata01-lv04   (253, 3) pg_root
vgdata01-lv03   (253, 2) pg_xlog
vgdata01-lv02   (253, 1)
vgdata01-lv01   (253, 0)

文件系统

mkfs.xfs -f -b size=4096 -l logdev=/dev/mapper/vgdata01-lv01,size=2136997888,sunit=16 -d agsize=524280k,sunit=16,swidth=32 /dev/mapper/vgdata01-lv03
mkfs.xfs -f -b size=4096 -l logdev=/dev/mapper/vgdata01-lv02,size=2136997888,sunit=16 -d agsize=524280k,sunit=16,swidth=32 /dev/mapper/vgdata01-lv04

mount -t xfs -o allocsize=1GiB,inode64,nobarrier,largeio,logbufs=8,logbsize=262144,noatime,nodiratime,swalloc,logdev=/dev/mapper/vgdata01-lv01 /dev/mapper/vgdata01-lv03 /u01
mount -t xfs -o allocsize=1GiB,inode64,nobarrier,largeio,logbufs=8,logbsize=262144,noatime,nodiratime,swalloc,logdev=/dev/mapper/vgdata01-lv02 /dev/mapper/vgdata01-lv04 /u02

目录

#mkdir /data01/digoal
#mkdir /data02/digoal
#chown digoal /data01/digoal
#chown digoal /data02/digoal

IOPS限制不一样的地方,不限制XFS的LOG设备(只是xfs metadata journal)。

$ vi start.sh
for ((i=1921;i<1921+$1;i++))
do
  . /home/digoal/env.sh $i
  cgcreate -g cpu:RULE$i
  cgcreate -g cpuacct:RULE$i
  cgcreate -g memory:RULE$i
  cgcreate -g blkio:RULE$i

  echo "253:2 4000" > /cgroup/blkio/RULE$i/blkio.throttle.write_iops_device
  echo "253:2 4000" > /cgroup/blkio/RULE$i/blkio.throttle.read_iops_device
  echo "253:3 800" > /cgroup/blkio/RULE$i/blkio.throttle.write_iops_device
  echo "253:3 800" > /cgroup/blkio/RULE$i/blkio.throttle.read_iops_device
  echo "70" > /cgroup/cpu/RULE$i/cpu.shares
  echo "1000000" > /cgroup/cpu/RULE$i/cpu.cfs_period_us
  echo "700000" > /cgroup/cpu/RULE$i/cpu.cfs_quota_us
  echo "1000000" > /cgroup/cpu/RULE$i/cpu.rt_period_us
  echo "1000" > /cgroup/cpu/RULE$i/cpu.rt_runtime_us
  echo "4294967296" > /cgroup/memory/RULE$i/memory.limit_in_bytes

  cgexec -g cpu:RULE$i -g cpuacct:RULE$i -g memory:RULE$i -g blkio:RULE$i su - digoal -c ". ~/env.sh $i ; nohup postgres -B 1GB -c port=$i -c listen_addresses='0.0.0.0' -c synchronous_commit=on -c full_page_writes=on -c wal_buffers=128MB -c wal_writer_flush_after=0 -c bgwriter_delay=10ms -c max_connections=100 -c bgwriter_lru_maxpages=1000 -c bgwriter_lru_multiplier=10.0 -c unix_socket_directories='.' -c max_wal_size=16GB -c checkpoint_timeout=50min -c checkpoint_completion_target=0.00001 -c log_checkpoints=on -c log_connections=on -c log_disconnections=on -c log_error_verbosity=verbose -c autovacuum_vacuum_scale_factor=0.002 -c autovacuum_max_workers=4 -c autovacuum_naptime=5s -c random_page_cost=1.0 -c constraint_exclusion=on -c log_destination='csvlog' -c logging_collector=on -c maintenance_work_mem=256MB -c autovacuum_work_mem=256MB -D $PGDATA -k $PGDATA >/dev/null 2>&1 &"

done

性能和稳定性表现

同样的测试方法下面,我们来看看

润滑性,在测试了7个小时后,表现很不错,没有出现完全hang的情况,而在EXT4下面则出现了长时间hang住的情况,此时PSTACK指向的也是ext4的操作。

检查点fsync时长都这样了,只是性能略微下降,没有出现hang死。

checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 47243 buffers (36.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=59.004 s, sync=0.995 s, total=60.129 s; sync files=39, longest=0.696 s, average=0.025 s; distance=998569 kB, estimate=998569 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""
checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 91660 buffers (69.9%); 0 transaction log file(s) added, 0 removed, 61 recycled; write=82.958 s, sync=33.343 s, total=116.809 s; sync files=8, longest=32.943 s, average=4.167 s; distance=1362303 kB, estimate=1362303 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""
checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 128232 buffers (97.8%); 0 transaction log file(s) added, 0 removed, 83 recycled; write=2.489 s, sync=165.609 s, total=168.324 s; sync files=10, longest=162.110 s, average=16.560 s; distance=2058155 kB, estimate=2058155 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""
checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 114122 buffers (87.1%); 0 transaction log file(s) added, 0 removed, 126 recycled; write=3.176 s, sync=149.814 s, total=153.458 s; sync files=9, longest=146.011 s, average=16.646 s; distance=2543291 kB, estimate=2543291 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""
checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 114991 buffers (87.7%); 0 transaction log file(s) added, 0 removed, 155 recycled; write=5.199 s, sync=168.901 s, total=176.056 s; sync files=9, longest=149.837 s, average=18.766 s; distance=3013867 kB, estimate=3013867 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""
checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 112645 buffers (85.9%); 0 transaction log file(s) added, 0 removed, 184 recycled; write=2.360 s, sync=193.048 s, total=196.096 s; sync files=9, longest=154.145 s, average=21.449 s; distance=3550585 kB, estimate=3550585 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""
checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 61261 buffers (46.7%); 0 transaction log file(s) added, 33 removed, 183 recycled; write=222.717 s, sync=194.187 s, total=424.427 s; sync files=10, longest=89.013 s, average=19.417 s; distance=3990374 kB, estimate=3990374 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""
checkpoint starting: time",,,,,,,,"LogCheckpointStart, xlog.c:7996",""
checkpoint complete: wrote 50192 buffers (38.3%); 0 transaction log file(s) added, 115 removed, 129 recycled; write=251.693 s, sync=546.324 s, total=811.781 s; sync files=8, longest=256.978 s, average=68.290 s; distance=4305749 kB, estimate=4305749 kB",,,,,,,,"LogCheckpointEnd, xlog.c:8078",""

性能方面,XFS表现完全超越EXT4。

如果你不想通过修改PG内核,优化检查点代码来提升稳定性的话,推荐使用XFS

Count

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
存储 弹性计算 运维
阿里云服务器ECS经济型e实例详细介绍_性能测试和租用价格
阿里云服务器ECS经济型e实例详细介绍_性能测试和租用价格,阿里云服务器ECS推出经济型e系列,经济型e实例是阿里云面向个人开发者、学生、小微企业,在中小型网站建设、开发测试、轻量级应用等场景推出的全新入门级云服务器,CPU采用Intel Xeon Platinum架构处理器,支持1:1、1:2、1:4多种处理器内存配比,e系列性价比优选
|
数据采集 自然语言处理 数据库
深入体验阿里云通义灵码:测试与实例展示
阿里云通义灵码是一款强大的代码生成工具,支持自然语言描述需求,快速生成高质量代码。它在测试、代码质量和用户体验方面表现出色,能够高效地生成 Python 和 Java 等语言的代码,助力开发者提升开发效率和代码质量。无论是新手还是资深开发者,都能从中受益匪浅。
深入体验阿里云通义灵码:测试与实例展示
|
机器学习/深度学习 JSON 算法
实例分割笔记(一): 使用YOLOv5-Seg对图像进行分割检测完整版(从自定义数据集到测试验证的完整流程)
本文详细介绍了使用YOLOv5-Seg模型进行图像分割的完整流程,包括图像分割的基础知识、YOLOv5-Seg模型的特点、环境搭建、数据集准备、模型训练、验证、测试以及评价指标。通过实例代码,指导读者从自定义数据集开始,直至模型的测试验证,适合深度学习领域的研究者和开发者参考。
4878 3
实例分割笔记(一): 使用YOLOv5-Seg对图像进行分割检测完整版(从自定义数据集到测试验证的完整流程)
|
设计模式 SQL 安全
PHP中的设计模式:单例模式的深入探索与实践在PHP的编程实践中,设计模式是解决常见软件设计问题的最佳实践。单例模式作为设计模式中的一种,确保一个类只有一个实例,并提供全局访问点,广泛应用于配置管理、日志记录和测试框架等场景。本文将深入探讨单例模式的原理、实现方式及其在PHP中的应用,帮助开发者更好地理解和运用这一设计模式。
在PHP开发中,单例模式通过确保类仅有一个实例并提供一个全局访问点,有效管理和访问共享资源。本文详细介绍了单例模式的概念、PHP实现方式及应用场景,并通过具体代码示例展示如何在PHP中实现单例模式以及如何在实际项目中正确使用它来优化代码结构和性能。
211 2
|
Java 测试技术 API
SpringBoot单元测试快速写法问题之创建 PorkInst 实例如何解决
SpringBoot单元测试快速写法问题之创建 PorkInst 实例如何解决
|
存储 测试技术 API
apifox实例应用-自动化测试用例for循环的使用
总结来说,通过在Apifox自动化测试用例中结合for循环的使用,我们可以有效地对接口进行批量测试,提升测试效率和覆盖率。同时,通过参数化测试数据的灵活应用,能够确保我们的接口在不同的输入条件下都能保持正确的行为。这种方法能够显著减少手动测试工作量,同时通过标准化的流程确保测试的一致性。
842 0
|
NoSQL 关系型数据库 MySQL
软件测试之【基于开源商城系统fecmall功能测试项目实例】
软件测试之【基于开源商城系统fecmall功能测试项目实例】
1210 0
软件测试之【基于开源商城系统fecmall功能测试项目实例】
|
DataWorks NoSQL 关系型数据库
DataWorks操作报错合集之在使用 DataWorks 进行 MongoDB 同步时遇到了连通性测试失败,实例配置和 MongoDB 白名单配置均正确,且同 VPC 下 MySQL 可以成功连接并同步,但 MongoDB 却无法完成同样的操作如何解决
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
286 1
|
测试技术 Android开发
快速上手App自动化测试利器,Toast原理解析及操作实例
`Toast`是Android中的轻量级通知,短暂显示在屏幕任意位置,1-2秒后自动消失,不获取焦点且不可点击。Appium通过uiautomator2在控件树中处理Toast。在测试中,可设置隐式等待,利用XPath或Accessibility ID定位Toast元素进行检测和验证。示例代码展示了如何初始化driver,点击触发Toast,以及如何定位并读取Toast文本。
java面向对象高级分层实例_测试类(main方法所在的类)
java面向对象高级分层实例_测试类(main方法所在的类)

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版
  • 推荐镜像

    更多