3个节点
96c cpu 、 256G内存
现在每台上都部署pd、TiDB、tikv
那么配置如何优化， 比如cpu 如何分配？
谢谢，这个文档我看过，
里面「TiKV 使用的 CPU 线程数的 80%」
我不确认的是比如一个节点部署了tidb\tikv\pd，我一个节点96c， 常规应该是给tikv多少cpu？
96c cpu 可以考虑numa绑核
我基于7.5版本测试混合部署3tikv 1pd 1tidb,比较关键的参数:
tikv的storage.block-cache.capacity
tidb的SET GLOBAL tidb_server_memory_limit = “32GB”
这两个设置合适值，看你打算起几个tikv几个tidb
谢谢，我是3个节点，每个节点部署1个tib kv pd； 这样也需要绑核吗， 我看文档上介绍的是说一个节点部署多个相同实例 会绑
另外：有没有其他默认安装，生产需要关闭或者调整的参数…
可以测试下， tidb有tpcc sysbentch压测组件可以tiup部署，然后你跑几天试试会不会oom，绑不绑核效果
1 个赞
首先tikv和pd都必须三个的，而且基于可用性考虑，他们三个必须一人一台服务器，而由于他们都需要持久化，我建议他们使用不同的磁盘，首先排除io的互相干扰
tidb-server只部2个就可以，宕机一台也不影响业务，看下机器是不是有2个或以上numa node，2个的话建议有部署tidb-server和tikv在一起的，通过numa隔离一下，3个的话把tidb-server，pd，tikv都通过numa隔离
tiflash暂时可以不上，毕竟机器不够
其他monitor和grafana都部署到没有部署tidb-server那台机器吧，这也算资源最大化了。
numa节点不够或者想要从参数限制 的话，
tikv的storage.block-cache.capacity大概设置256/3*0.45≈40G左右就可以，防止oom
tidb的SET GLOBAL tidb_server_memory_limit = “80GB”，一个节点上既有pd，又有tikv，又有tidb，设置80G左右吧，太多了别影响其他服务了
3 个赞
这种情况，我们一般是每台上都部署一个pd、tidb、tikv，然后使用默认配置。
会有资源抢占问题吧， 我考虑限制tidb和tikv的内存上限， 这个有没有参考值，比如tidb和tikv的比例，或者我们256g的内存，按经验一般给他们分多少呢
是不是有必要设置tikv的memory-usage-limit ，我看社区里说，tikv内存控制不住，因为没设置这个参数， 这个一般设置多少合适呢
开始尽量少分，内存多留点，storage.block-cache.capacity给个30G tidb_server_memory_limit 给32G，先跑跑看看，具体每个进程占用
不需要，设置storage.block-cache.capacity就可以，tikv总内存不会超过这个值的2.5倍
1、看一下服务器是否为numa，是的话几个numa node；
2、混合部署的话，建议tidb max-procs/memory配置一下，限制tidb-server的cpu和内存；
3、给pd留8G～16G内存，tikv block-cache按照总内存-pd内存-tidb内存的45%设置；
4、机器cpu和内存都比较高，建议可以考虑一台机器部署2个tikv+1tidb或者2tidb+1tikv，根据实际业务来看；
3节点服务器的TiDB-cluster集群，部署建议如下：
- TiDB-Server 部署
-
节点分配：
- 在其中的2个节点上均部署TiDB-Server。
- TiDB-Server可以处理读写请求，并且能够自动在节点间进行负载均衡。
-
资源分配：
每个节点上分配足够的CPU和内存资源以运行TiDB-Server。由于您有96个核心和256G内存，可以根据实际工作负载需求分配资源。
通常，TiDB-Server不需要像TiKV那样多的资源，但仍然需要足够的资源来处理事务和查询。
- PD (Placement Driver) 部署
-
节点分配：
- 在3个节点上均部署PD。
- PD负责维护集群的状态，包括元数据和Placement Rules。
-
资源分配：
- 由于PD的资源需求相对较低，每个节点上可以分配较少的CPU和内存资源。
- 分配足够的资源以保证PD可以高效地处理集群管理任务。
- TiKV 部署
-
节点分配：
- TiKV是分布式存储系统，每个节点上都会存储数据。
- 在3个节点上均部署TiKV。
-
资源分配：
- TiKV是资源密集型的，每个节点都需要分配较多的CPU和内存资源。
- 考虑到您有96个核心和256G内存，可以为每个TiKV节点分配足够的资源来处理大量的读写操作。
- 配置参数优化
TiDB-Server：
tidb:
log.level: error
new_collations_enabled_on_first_bootstrap: true
performance.max-procs: 40
performance.txn-total-size-limit: 42212254720 //如果是OLTP业务，建议设置太大，容易产生OOM
prepared-plan-cache.enabled: true
tidb_mem_oom_action: CANCEL
tidb_mem_quota_query: 10737418240 //如果是OLTP业务，建议设置太大，容易产生OOM
tmp-storage-path: /acdata/tidb-memory-cache
tmp-storage-quota: -1
PD：
调整server.toml中的[cluster-version]以匹配TiDB和TiKV的版本。
确保[metric]配置符合监控需求。
TiKV：
tikv:
coprocessor.region-max-size: 384MB
coprocessor.region-split-size: 256MB
raftstore.region-split-check-diff: 196MB
raftstore.store-pool-size: 2
readpool.coprocessor.use-unified-pool: true
readpool.storage.use-unified-pool: false
readpool.unified.max-thread-count: 48
server.end-point-concurrency: 48
server.grpc-concurrency: 48
storage.reserve-space: 0MB
storage.scheduler-worker-pool-size: 48
- 提升创建索引效率
SET @@global.tidb_ddl_enable_fast_reorg=on;
SET @@global.tidb_ddl_reorg_batch_size = 10240;
SET @@global.tidb_ddl_reorg_worker_cnt = 32;
能用numa就用numa绑核部署，一个组件一个核就还好
按大佬说的试下这个，storage.block-cache.capacity
tidb_ddl_reorg_worker_cnt = 32;是不是太多了
业务量不大还行
配置上cpu限制
不是有资源隔离的功能嘛