【 TiDB 使用环境】生产环境
3节点混部，怎么优化参数配置？官方文档上的混部参数试了一轮，感觉没什么效果
测试使用的是 8c*64G ssd盘 3 节点混部
sysbench压测混合读写，3个节点总和的值还不如mysql
3节点同时跑，128线程 10个1000万的表，各节点：TPS 500/s，QPS 1万/s，95延迟 25ms
除了提升服务器规格，还有没有可以提升的方式方法？
https://docs.pingcap.com/zh/tidb/v7.1/three-nodes-hybrid-deployment
看看这个
至于sysbench不如mysql，分析下监控，看看是不是线程数不够。通过增加线程数能不能超过mysql
找到qps不能增加的线程数，然后一直压测，看看是tidb还是tikv压力大。然后进一步分析。
1 个赞
你把架构贴出来 我们看看
先按这个兄弟说的按官网配置下，然后看下服务器资源瓶颈在哪里
- gogc 参数：
- 默认值：100
- 建议调整范围：可以设置为 1000（或更高），但需监控内存使用情况和 GC 引起的性能抖动。
- NUMA 绑定：
- 使用
numactl --interleave=all命令来启动 TiDB 服务，以实现 NUMA 内存的交错访问。
- 线程池参数：
readpool.unified.max-thread-count：根据 CPU 核心数和业务负载调整，例如，如果每节点有 8 个核心，可以设置为8 * 0.8 = 6，然后根据监控调整。storage.scheduler-worker-pool-size：根据 TiKV 处理能力调整，可以从默认值开始，根据 CPU 利用率调整。
- 后台任务资源限制：
rocksdb.max-background-jobs：根据 SSD 性能和写入负载调整，可以从默认值 2 开始调整。rocksdb.max-sub-compactions：调整范围通常在 1 到 4 之间，根据写入负载和 compaction 性能调整。rocksdb.rate-bytes-per-sec：根据磁盘的顺序写入速度设置，以限制后台 compaction 的影响。
- 监控与分析：
- 利用 TiDB Dashboard、Prometheus 和 Grafana 等工具监控关键指标，根据监控数据调整参数。
- 网络和 CPU 资源争抢：
- 确认网络软中断是否对 CPU 造成压力，使用
mpstat等工具监控 CPU 状态。
- SQL 执行计划稳定性：
- 使用
EXPLAIN或EXPLAIN ANALYZE分析慢查询的执行计划，根据需要调整索引或使用 SQL Binding。
- 版本更新：
- 考虑升级到最新稳定版本以利用新特性和性能改进。
强在复杂的读吧，写可能也不是tidb的强项
默认参数应该就够用了
没啥好调整的，3节点是很难跑过mysql的
l架构就是3台 8C 64G 的服务器，每台上各部署一个 pd\tikv\tidb
最好不要混不
如果一定要混合 做好tikv和tidb的隔离
tidb和mysql 侧重点不一样 mysql主从得手动切换
读写业务无法分离
性能tidb打不过mysql
但mysql 会丢数据
时不时重启 binlog异常这种问题你都可以不用处理了
说实话，TiDB就不太适合混合部署，混合部署很容易造成组件之间争夺资源，业务量上来一点就很容易把组件给搞得自动重启，比如一旦内存不足就很容易把内存消耗最多的组件进程给干掉，我们之前混合部署就遇到过好几次TiKV节点自动重启，就是因为TiKV组件进程消耗内存排前面，所以首先就Kill它。
1 个赞
有时候还是宁愿各个节点的资源少一点，但是节点多一点，存储节点和计算节点分开部署，而不是节点少，资源多，但是存储和计算节点混合在一起部署。
别混合部署
你可以把当前配置和集群监控发出来看看，是不是有热点之类的问题。只是描述结果很难帮你看呀
根据架构进行配置
测试、学习的话，混部搞搞还可以，生产的话，不建议……
文档里面有专门针对这种混部的部署方法。 