- 【TiDB 版本】:3.0.18
- 【问题描述】:
新建了一套集群,在做一些业务压测,和优化测试。
发现新集群的tidb-server cpu使用率非常高,4000%居高不下。
即便服务器有96线程,但这看起来非常不正常,
相比原集群, 新集群做了一些优化尝试:
- 开启静默region
- 引入分区表
- 删除了主键,解决热点问题。
新建了一套集群,在做一些业务压测,和优化测试。
发现新集群的tidb-server cpu使用率非常高,4000%居高不下。
即便服务器有96线程,但这看起来非常不正常,
相比原集群, 新集群做了一些优化尝试:
curl -G http://{TiDBIP}:10080/debug/zip?seconds=30" > profile.zip 请反馈火焰图
ip地址为tidb服务器的ip,端口为tidb_status_port的端口
麻烦上传 tidb-server 和 over-view 的监控图
从 pprof 看可能和分区表有关(虽然看不到之前的 pprof)
看 CPU 主要消耗在 compile 和 execute 两个过程,从最下层看比较明显的是 getStats 和 分区裁剪中的内存分配,而分配数量会导致左边 bgMarkWoker 的消耗, 而这两个从 pprof 看主要是分区表引入的 cost
这两块将在 5.0 有改进(合并分区统计信息减少和分区裁决优化)
感谢回复。
引入分区表,是想解决历史数据归档清理效率的问题。
目前是按月分区,保留较少(3个月)的分区,让业务查询不必额外添加字段,来命中分区剪裁。
看起来扫描所有分区,开销还是挺大的…
上述场景还有其他的解决方案吗?
抱歉,对于当前版本在要求性能较高的场景还是推荐不做全分区扫描或暂时先不使用分区表特性,我们会努力改进
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。