请问混合部署3个节点，每个节点都有组件tidb,tikv,pd，那这个参数设置多大合理呢？
64核CPU，目前其中有一个节点业务高峰期CPU达以5000左右就爆了，非常卡，也有可能是热点引起的一个节点CPU爆涨，业务空闲就降下来了。如果把readpool.unified.max-thread-count这个参数降低会不会解决CPU爆的问题呢？
简单的调整参数没有作用吧。
还是找到高CPU的原因，优化慢SQL、热点等。调低，处理能力降低，可能整体响应就变慢了，业务更慢咋整。
写入线程合计控制在 32 以内，读写线程总和控制在 50 以内，预留资源给 TiDB+PD
1.如果支持绑 numa，可以让 tikv 独享一个 numa，并根据单个 numa cpu 个数设置 unified read pool 线程池大小
2. 若不支持，该参数默认 cores * 0.8，混布的情况下可以适当调小，注意调小后业务可能受影响，建议观察一段时间的峰值再调整
3. 解决热点问题，避免单实例 cpu 打满
调低线程池治标不治本，会压缩查询算力、拖慢业务
内存飙升可以看看 TiDB Dashboard 的 SQL 分析，把内存消耗最高的查询找出来优化一下。另外可以把 tidb_mem_quota_query 参数调小，避免单个查询把内存撑爆。
TiDB 的 OOM 经常跟算子下推有关，比如 hash join 或 hash agg 在内存不足时不会 spill 到磁盘。从根本上说，建议从数据分布和查询模式入手，减少大表 JOIN 和全量扫描，利用 Region 级别的并行计算来分摊内存压力。
1、排查优化慢 SQL、消除数据热点；管控单查询内存限制，优化大表关联 / 聚合等易致内存溢出的 SQL。
2、 保留现有集群，新增专用节点，把高 CPU、高并发的业务迁移到独立 TiKV/TiDB 节点，原节点只承载低负载业务，同时给 TiKV 读写线程预留充足资源。
3、按业务维度拆分为多个独立 TiDB 集群，核心高负载业务单独一套集群，普通业务共用一套，完全规避资源争抢与节点热点。
4、 拆分后再配合参数调优：独立节点按 CPU 核数合理设置readpool.unified.max-thread-count；同时继续优化慢 SQL、打散数据热点，双重保障稳定性。
排查SQL
内存飙升可以看看 TiDB Dashboard 的 SQL 分析，把内存消耗最高的查询找出来优化一下。另外可以把 tidb_mem_quota_query 参数调小，避免单个查询把内存撑爆。
SQL优化是一方面，如果是SQL问题引起的，不至于总是一个节点的KV负载高吧，另外两个节点相对空闲。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。