背景:
甲方表面上让你选型数据库, 其实只能选国产的磐维数据库, 其它家国产库都不是亲生的~~~
- 磐维数据库为分布式版本 居然分布式和集中式完全两批人开发的.........
- 推广期生产问题定位
问题:
一个普普通通的业务, 导入个几千条的文件, 居然出现了卡20分钟没结束的情况, 这背后究竟是..........
解决:
启动arthas trace该方法的执行
发现卡在查询机构表的地方, 经检查此表0条记录, 存在大量pg进程涉及此表, 此表占用空间16GB
发起外部会议 磐维数据库方给出的解释为
-
表空间的回收是异步的, delete操作时仅标记dead tuple死元数据, 周期性真实回收空间--即使delete all也是如此
-
故查询时实际是查了16G的数据还没走索引
-
truncate可以立刻回收空间
-
如果没回收说明表资源占用
查到最后查到一个小开发头上
- 早期发版时客户摇摆不定, 需求各种变动, 发布测试环境不规范, 其配的定时任务同步这个表时, 配了个* 0 2 每天2点每秒都执行, 导致此表无法回收死元数据
规范:
初期尽早确认发版规范
执行上线内容(git)审计制度
可以的话, 使用成熟数据中台同步数据
选型阶段加强与涉及数据释放, 锁 ,事务 驱动的沟通, 详细调研学习
