scheduler 线程CPU打满，lightning导入数据非常慢

errnil · 2020 年8 月 7 日 04:05

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

【TiDB 版本】：V4.0.2
【问题描述】：
ligthing导入数据，开始正常，但几分钟后，性能急剧下降，lightning导入速度降到几乎为0。可以看到某个tikv的CPU很高， storage.scheduler-worker-pool-size: 8， scheduler的CPU为800%， scheduler pending command大幅上升
其它线程CPU看起来正常，也不高， SSD硬盘， IO也不高。重启该CPU高的节点后，会转移到其它节点CPU高。目标表已经有不少数据，lightning导入后端为tidb。

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出打印结果，请务必全选并复制粘贴上传。

yilong · 2020 年8 月 7 日 05:43

请问使用的是 backend 模式导入吗？
麻烦反馈下 over-view pd detail-tikv 的监控
(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

errnil · 2020 年8 月 9 日 04:08

1 是的， backend的模式导入, 配置如下：
[tikv-importer]
backend = “tidb”
on-duplicate = “replace”

2 tikv detail太多指标了，页面没响应了，试了多次也不行。我截屏了tikv trouble
原始PDF太大了，上传不了，我压缩了再上传
over_view_s_compressed.pdf (495.3 KB) pd_s_compressed.pdf (815.5 KB) tikv_trouble_s_compressed.pdf (892.8 KB)

yilong · 2020 年8 月 10 日 03:30

整体 cpu 有一些主机打满达到了 100%

image1589×416 126 KB
add learner 延时很高了

image1603×899 148 KB
hot write 的 cpu 有几个节点很高，存在热点写入

image1568×780 249 KB
由于您使用了 TiFlash，能否先尝试先关闭 TiFlash，导入数据后，再开启 TiFlash同步。

errnil · 2020 年8 月 10 日 03:54

1 CPU都很高，热点节点不停转移。但实际这个时候没什么数据在写入了，因为都写不进去了，然而CPU一直持续这么高

2 我把lighting停了，把scheduler线程CPU满的tikv节点重启了，写入就正常了, scheduler的CPU没满了。目前这个tidb集群，没有查询，还处于导入数据阶段，目前是通过DM在导入数据。因为从多个数据库导入相关的表，有部分重复的数据， DM导入全量数据不支持insert改为insert ignore或者replace, 因此lightning与DM一块使用

3 给表加索引时，也出现两样的现象， scheduler线程CPU满，基本没法写入

4 把lighting停了，把加索引的DDL过滤后， DM数据导入正常，虽然CPU也很高，但scheduler CPU不会满，插入的QPS为2000左右，而异常时insert基本只有个位数QPS

5 tiflash开户了，但目前没有设置表的同步为tiflash

6 只要把scheduler线程CPU满的节点重启了，写入会正常一会，然后某个节点的scheduler线程CPU会打满，然后基本就处于整个集群CPU持续高，数据基本写不入的情况了

yilong · 2020 年8 月 10 日 06:19

由于没有 detail-tikv 监控，麻烦按照以下 4.5.2 检查下监控信息

image1242×365 64.8 KB
您的意思是停止导入后，scheduler cpu 还是一直高吗？

errnil · 2020 年8 月 10 日 07:53

1 是prewrite很慢。scheduler-worker-pool-size我调到8， scheduler线程CPU就去到800%，调到16，scheduler线程CPU就去到1600%。实际上这个时候，已经基本写不入了，但是我没关闭lightning，让它持续这样跑了24小时，这24小时都基本这样，基本没法写入，CPU又一直这么高

2 停止导入lightning导入后， CPU也高，但没这么高，能正常能过DM导入数据，也没有出现scheduler cpu一直很高的现象。下面是现在关闭了ligtning只有DM在同步数据的CPU情况, 可以看到CPU依然很高，但scheduler cpu没有满， statement ops看到数据正在导入，没有出现statement ops只有个位数而CPU就极高的现象

yilong · 2020 年8 月 10 日 09:39

麻烦发一下 CPU 高的时候 rocksdb - kv 的 metrics，多谢。

errnil · 2020 年8 月 10 日 11:02

rocksdb_kv_s_compressed.pdf (427.5 KB)

errnil · 2020 年8 月 11 日 02:40

看来可能是region的分裂太频繁了导致。我下面的设置提高了差不多10倍，原来是700万key, 300多MB：
coprocessor.region-max-size: “10GB”
coprocessor.region-split-size: “6GB”
coprocessor.region-max-keys: 50000000
coprocessor.region-split-keys: 30000000

merge region的设置相应提高到下面的值
schedule.max-merge-region-size: 5000
schedule.max-merge-region-keys: 30000000

然后重启tikv与pd, dm的写入快了几倍， scheduler的CPU下降了几倍，tikv整体的CPU也下降了不少，而split check 的CPU几乎降到了0。就是不知道会不会数据持续写入后，达到region分裂的大小后，又会出现CPU好高，写入停滞的情况。也没有找到split check的线程数设置参数