tikv 热点算法问题 和 k8s 默认CPU计算

[h5n1]

：4.19.90-17.ky10.aarch64 、 k8s: v1.24.9 、operator: 1.4.0 、tidb 6.1.2
dyrnq/local-volume-provisioner:v2.5.0 (POD未调整时区)

sysbench 初始化10张1亿表 然后64线程oltp_read测试，发现tikv-1、tikv-4存在热点问题。按照截图时间做了如下操作
1 尝试了几次配置shuffle leader调度 ， 添加后热点tikv出现短暂下降后又立马回升。
2、对热点tikv添加 evict leader调度 ，热点tikv leader被驱逐后其他tikv利用率增高，删除evict 调度后，热点tikv立马回升到原来的利用率
3、对几个热点region做split ,并对一些热点region 做了手动调度，同样出现短暂下降后立马回升。

检查tikv QPS ，tikv-1 tikv-4 并不是最高

检查tikv 流量，tikv-1 tikv-4 并不是最高

检查热力图 读流量看没有明显的表

检查uinified read pool设置，发现tikv-1 tikv-4的max 为76 其他为12

检查cluster设置 为设置unified pool参数 且 pod设置的是16C

调整unified read max thread count 参数为12，重启后无效果

通过pd-ctl store weight 调整热点leader weight 的权重为0 ，有部分leader未迁移(约12%，是当前其他节点的0.08%)，有一点点的效果

检查read 的热点region, 看上去2个tikv 似乎并比重并不多，流量也是最低的

把tikv-4（storeid 8）上的3个top read region 转移到其他store， cpu出现短暂下降后立马又回升。

再次对2个热点tikv 添加evict leader 调度之后删除，保持sotre leader weight 为0 ，删除调度后2个tikv上仅有7个leader ,但2个tikv的CPU利用率 依然很高。

【问题】
1、 tikv-1 tikv-4的配置的readpool.unified.max-thread-count为76 (主机96C 的80%)，超出了pod资源设置的16C ，看上去把主机的物理cpu数量作为了cpu count计算，为什么会出现这种情况？

2、 从前面的处理方式 监控数据看 ，尤其第二次evict leader + leader_weight=0 ，readpool.unified 的CPU利用率 是和2个tikv max-thread-count计算出76个来有某种联系，否则这种现象也太过于巧合了。

3、 leader weight 的计算百分比是到多少位？

@yiduoyunQ @neilshen 请2位大佬看看。

[yiduoyunQ]

1. 按官网描述似乎符合预期？
   
   

我不熟 TiKV，可以去 TiKV repo 里提个 issue 看下这种 case 是否符合预期

[h5n1]

如果是物理部署的 76是正确的，不知道k8s上加上pod资源限制后是如何决定的，无论那种判断逻辑，所有的tikv的参数值应该保持一致才对

[tidb狂热爱好者]

被判断为物理核心数量了 出现穿透

[tidb狂热爱好者]

说明numa绑定核心未生效

[h5n1]

@yiduoyunQ 大佬，tidb数据库是如何获的pod的cpu limit ? 或者说在识别Pod的cpu limit时是个什么样的途径或过程？

[yiduoyunQ]

operator 本身不会干涉调度具体逻辑（admission-webhook 相关的目前基本没做啥功能可以忽略），operator 做的事类似根据 TC 配置创建相应 sts 和相关资源，之后由 k8s 自动完成 pod 创建调度等，和 numa 相关的可以参考 https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/configure-a-tidb-cluster#资源配置

[h5n1]

不知道我的问题是否是和numa有关，个人感觉没啥关系，3台主机，每个96c ，4个numanode , 如果是某个tikv进程跨numa node分配了CPU 会导致该tikv获取的cpu count是整个主机cpu数量吗

[pingyu]

TiKV 通过解析 cgroup 设置获得 cpu、cpuset 等限制。可能是 cgroup 没设置成功，也可能是 TiKV 解析失败

可以在 tikv log 中搜索 cgroup quota，查看解析的结果（大概这个样子：[2023/02/02 09:46:28.089 +08:00] [INFO] [mod.rs:79] ["cgroup quota: memory=Some(9223372036854771712), cpu=None, cores={2, 1, 5, 18, 28, 12, 13, 34, 35, 33, 31, 29, 25, 39, 0, 32, 38, 22, 7, 8, 20, 6, 10, 11, 16, 26, 4, 15, 14, 37, 17, 19, 21, 9, 23, 36, 27, 24, 30, 3}"]）

另外可以搜索 cgroup，看看是否有相关的 warning

然后可以检查一下 pod 中 cgroup 的设置，包括 /proc//cgroup、/sys/fs/cgroup//cpu.max（或 cpu.cfs_quota_us/cpu.cfs_period_us）、/sys/fs/cgroup//cpuset.cpus（或 cpuset.cpus）等等

[h5n1]

感谢大佬。
1、 有问题的2个tikv kubectl logs 查看cgroup quota有如下信息，其他正常的4个没有找到cgroup quota关键字
tikv1 log

[2023/02/08 01:37:27.461 +00:00] [INFO] [mod.rs:74] ["cgroup quota: memory=None, cpu=None, cores={}"]

tikv4 log

[2023/02/08 01:37:27.040 +00:00] [INFO] [mod.rs:74] ["cgroup quota: memory=None, cpu=None, cores={}"]

2、 检查cgroup设置，有问题的2个tikv都在同一台主机上，有目录 /sys/fs/cgroup/cpuset/containerdID/ ,其中 cpuset.effective_cpus cpuset.cpus 中内容为0-95 ，其他2台上没有上述包含 containerdID 的目录。感觉应该是cgroup资源隔离配置上有差异。
3、检查发现有问题的这台上 containerd的配置文件中设置的是 SystemdCgroup=false，修改后重启正常