求教一个 Citus 数据库集群的磁盘 io 优化问题

事情是这样子的：

我们有一个用于生产用的 Citus 集群，但是速度一直很慢

我们曾经优化过很长一段时间，但是最后都无一例外的扛不住我们的数据压力

我们遇到的问题是大规模数据入库的时候磁盘写入等待时间每次都暴涨

数据库的配置如下

32 核心 128GB 私有云服务器，挂载磁盘 20TB

目前在跑的数据库

citus11 postgresql15

分片数 80 ，副本数 2 ，并发是 114 ，每个连接都在执行 copy 任务，每个任务每次要入 10 万条数据。实际测试发现无论并发多少都是写一会数据库服务器的磁盘 io 时间就巨长。

有哪些数据库配置参数或者其它要改的东西吗？

求各位大佬看看，孩子只是个后端写数据流程的新手，已经对着 citus 和 pg 的参考手册把头都改秃噜了

litguy

2023 年 1 月 16 日

磁盘 io 时间巨长，说明 io 是瓶颈啊，磁盘是 HDD 还是 SSD 的卷？
这个问题很好检测，最简单的是在物理机重现
每个物理机挂 NVME 的固态盘（企业级）
看看还有无问题
没有，就是你们挂载的存储卷 io 性能太差了
可以用 fio 单独测测这个卷的性能

ayogo

2023 年 1 月 16 日

@litguy @v2wtf 不好意思的大佬们，我没描述清楚。我们目前的磁盘配置是使用集中式存储，是 SSD 混合 HHD ，走的是 hba 卡的光纤。目前我们遇到的问题就是 copy 写入数据一个小时到两个小时之后，数据库磁盘的写入等待时间会从 200-1000ms 急剧飙升到 20000ms+，平均每台机器的写 IOPS 在 200 左右。固态和机械的比例我不知道，我个人觉得很可能是集中式存储的磁盘缓存被写满了。但是运维那也没给我太对有用的信息。(／_＼)

ayogo

2023 年 1 月 16 日

@litguy 是有关语言处理模型的一些文本信息和数字编号，目前在处理的一张表里面有 9 行，40 亿数据，大部分编号长度都在 20 位以下。文本部分的长度基本上都在 20-60 字左右。

v2wtf

2023 年 1 月 16 日

IOPS 200 太低了，大概率是缓存写满了，直接写 HHD 上了。这么低的 IOPS ，你怎么优化系统、软件都没用（除非你有足够巨大的内存）。

说个数字：现代的 SSD 的 4K IOPS 达到 50 万轻而易举、稀疏平常，高端点多的能达到 90 万、100 万，你那 200 IOPS ，就跟玩具一样。

ayogo

2023 年 1 月 16 日

@v2wtf 是的，我之前也是很努力的在把写入磁盘的粒度调大，频率降低，然而还是遭不住。我其实很早之前反应过这个问题，也是按照大佬你的思路去汇报，但是没被接受。上级给出的答复是我们的数据中心换磁盘的成本太高(／_＼)。我已经摆烂了。

litguy

2023 年 1 月 16 日

混合阵列，SSD 作读写缓存，缓存击穿后就是你这个现象
我曾经是混合阵列的开发
现在作全闪
如果你们业务是全天候持续写入，还是上全闪吧
如果你们业务时定期突发性大批量写入，然后空闲，一定时间后再次大批量写入，可以调整混合阵列的 SSD 大小，翻倍看够不够，不够再翻倍，一句话，大小必须能接住这个阶段的写入数据；同时，写入后存储软件在下个写入阶段到来前，有足够时间把 SSD 的数据刷到后端 HDD 去，如果不满足这个限制，那就全闪
其实 SSD 的 4K IOPS 也没楼上哥们说那么高，突发短时间写入这个性能没问题，高强度持续写，消费级肯定歇菜，企业级 SSD 低端的也不行，50W 可不是稀疏平常

ayogo

2023 年 1 月 16 日

@litguy 感谢大佬能花时间给我答复！我们刚刚还发现了一个问题，就是针对这个数据库进行入库的时候磁盘 io 就暴涨，但是这个数据库的数据总量远远没有其它数据库多。我们下一步修改跟磁盘优先级有关的参数，要是再不行就寄了。明天晚上老板就要刀了我了_(:з」∠)_。话说回来我想问一下，50 亿行数据入到数据库集群一般需要花多久，我们公司没有 dba ，所以这一块一直是我在挑挑弄弄，之前我们跑 87 亿数据跑了 12 个小时，但是后来就再也没有那么快了。

litguy

2023 年 1 月 17 日

我感觉有点奇怪，如果你只是希望写入性能，可以看看别的数据库，尤其 LSM 引擎的
你这个系统非要用 PG ，那就升级磁盘
另外，低性能的外部存储，还不如本机挂几个盘自己玩呢

ayogo

2023 年 1 月 23 日

@litguy 我们目前发现的一个问题，因为全部的服务器的数据盘都挂载在集中存储服务器上，然后 pg_wal 缓冲区也被设在了数据盘上。我们估计应该是缓冲区被放到了集中式存储服务器上导致的读写 io 爆炸。另外，事后看了相关监控，发现实际上在生产中记录到的磁盘阵列的 IOPS 不是很低，读写都能到 10w 左右。没有之前提到的那么低。

litguy

2023 年 1 月 26 日

@ayogo 可以考虑本地挂载 NVME 盘作 PG_WAL ，日志盘不一定非要放在集中式存储上面，本地盘的延迟好得多，最坏的情况就是本地盘坏，丢失本节点最后写入的数据。你只要评估两个问题：系统是不是还有副本，如果有，其实不怕本结点 WAL 盘坏；如果没有，最后写入数据丢失要紧不要紧，如果不要紧，其实也无所谓。

ayogo

2023 年 1 月 27 日

@litguy 是的，我们前几天已经把 pg_wal 转移到了 SSD 上。性能优化了很多。下一步计划就是把数据盘换成本地的 SSD 。这些测试前几天我们都做过了，确实像大佬说的那样。数据库这块确实很吃经验，要学的东西还很多。感谢大佬的悉心指导！

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://study.congcong.us/t/909160

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.