1
liprais 2023-01-16 08:54:31 +08:00 via iPhone
一直往里面写不就完了
|
2
litguy 2023-01-16 09:08:24 +08:00
磁盘 io 时间巨长,说明 io 是瓶颈啊,磁盘是 HDD 还是 SSD 的卷 ?
这个问题很好检测,最简单的是在物理机重现 每个物理机挂 NVME 的固态盘(企业级) 看看还有无问题 没有,就是你们挂载的存储卷 io 性能太差了 可以用 fio 单独测测这个卷的性能 |
3
litguy 2023-01-16 09:09:38 +08:00
还有个问题,你们是什么类型的数据
业务场景能不能说得更细致一些 |
4
v2wtf 2023-01-16 09:17:57 +08:00
最重要的信息是磁盘配置情况,你却一个字都不提。
|
5
ayogo OP |
6
ayogo OP @litguy 是有关语言处理模型的一些文本信息和数字编号,目前在处理的一张表里面有 9 行,40 亿数据,大部分编号长度都在 20 位以下。文本部分的长度基本上都在 20-60 字左右。
|
7
v2wtf 2023-01-16 11:46:15 +08:00
IOPS 200 太低了,大概率是缓存写满了,直接写 HHD 上了。这么低的 IOPS ,你怎么优化系统、软件都没用(除非你有足够巨大的内存)。
说个数字:现代的 SSD 的 4K IOPS 达到 50 万轻而易举、稀疏平常,高端点多的能达到 90 万、100 万,你那 200 IOPS ,就跟玩具一样。 |
8
ayogo OP @v2wtf 是的,我之前也是很努力的在把写入磁盘的粒度调大,频率降低,然而还是遭不住。我其实很早之前反应过这个问题,也是按照大佬你的思路去汇报,但是没被接受。上级给出的答复是我们的数据中心换磁盘的成本太高(/_\)。我已经摆烂了。
|
9
litguy 2023-01-16 15:12:26 +08:00
混合阵列,SSD 作读写缓存,缓存击穿后就是你这个现象
我曾经是混合阵列的开发 现在作全闪 如果你们业务是全天候持续写入,还是上全闪吧 如果你们业务时定期突发性大批量写入,然后空闲,一定时间后再次大批量写入,可以调整混合阵列的 SSD 大小,翻倍看够不够,不够再翻倍,一句话,大小必须能接住这个阶段的写入数据;同时,写入后存储软件在下个写入阶段到来前,有足够时间把 SSD 的数据刷到后端 HDD 去,如果不满足这个限制,那就全闪 其实 SSD 的 4K IOPS 也没楼上哥们说那么高,突发短时间写入这个性能没问题,高强度持续写,消费级肯定歇菜,企业级 SSD 低端的也不行,50W 可不是稀疏平常 |
10
ayogo OP @litguy 感谢大佬能花时间给我答复!我们刚刚还发现了一个问题,就是针对这个数据库进行入库的时候磁盘 io 就暴涨,但是这个数据库的数据总量远远没有其它数据库多。我们下一步修改跟磁盘优先级有关的参数,要是再不行就寄了。明天晚上老板就要刀了我了_(:з」∠)_。话说回来我想问一下,50 亿行数据入到数据库集群一般需要花多久,我们公司没有 dba ,所以这一块一直是我在挑挑弄弄,之前我们跑 87 亿数据跑了 12 个小时,但是后来就再也没有那么快了。
|
11
litguy 2023-01-17 20:06:49 +08:00
我感觉有点奇怪,如果你只是希望写入性能,可以看看别的数据库,尤其 LSM 引擎的
你这个系统非要用 PG ,那就升级磁盘 另外,低性能的外部存储,还不如本机挂几个盘自己玩呢 |
12
ayogo OP @litguy 我们目前发现的一个问题,因为全部的服务器的数据盘都挂载在 集中存储服务器上,然后 pg_wal 缓冲区也被设在了数据盘上。我们估计应该是缓冲区被放到了集中式存储服务器上导致的读写 io 爆炸。另外,事后看了相关监控,发现实际上在生产中记录到的磁盘阵列的 IOPS 不是很低,读写都能到 10w 左右。没有之前提到的那么低。
|