有那条件那肯定啊。 原来是只有tikv numa 1绑定。 其他的 elasticsearch / python xxxx 都没做绑定 ，tikv出现oom。 然后想着tikv也不绑了 混着用，去掉tikv numa绑定后 出现这问题。 后来再绑上负载就下来了。

应该是的

服务器资源充足啊，256G内存，48核 内存available 还有67G 吧 ，tikv绑定了1，可能没绑的进程也随便用到了1 抢占资源

我实际试着，，，天差地别，我也以为应该没啥影响的所以才取消了。。

我回退了。。就好了，重新绑上numa负载就下来了， 业务上没啥变化

x86_64的

祝各位： 内卷无惧显身手，薪资升级最风流。 前途无量步步高，福气好运常相守。

这个说明了啥？

看过，都是一些整表的查询，， 可能是我表太大了，其实也说不太通，我的条件字段是有索引的，手动查询数据都是挺快的，不知道为啥这个这么慢

这个minio是正在使用的每天 br备份不同的库表数据，同一个用户密码一样的endpoint

不用远程存储，即使是存到本地硬盘上，都有问题。 [tidb@b67 ~]$ ~/tidb-toolkit/dumpling -u root -p 'xxxxx!pE' -P 4000 -h 192.168.241.85 -T bsppr.xpost --where "update_time < '2023-03-10 00:00:00'" -o /opt/dumpling/before-2023-03-01/ Release version: v7.1.5 Git commit hash: caa60c0917a886933a525d25e17057faac5b4da2 Git bra…

[image] 他这个是说用错了endpoint用成了console地址，但我用的是没问题的，因为我这个endpoint现在用在了br备份上，正常使用挺长时间了没有问题的~ 其他：因为br没法满足备份匹配条件的表数据，所以才想用dumpling备份条件数据的

这是执行命令后 连接的tidb的日志报错 [2024/11/12 16:37:46.391 +08:00] [INFO] [set.go:309] ["load snapshot info schema"] [conn=8441874356203684681] [SnapshotTS=453876296284110872] [2024/11/12 16:37:46.396 +08:00] [INFO] [set.go:309] ["load snapshot info schema"] [conn=8441874356203684683] [SnapshotTS=45387629628411…

我想说我这命令没问题吧？ 我好像不备份到minio，备份到本地也卡着，导不出数据。 我这个表数据量很大80亿左右，dumpling不支持导这么大数据的表吗？

没错的，我这不是s3，我这是备份到minio的 endpoint是生产的地址，内网IP 加hosts的

网络是通的，都是内网通讯，内网没限制

是的。

[image] 请求频率是没啥变化的