tikv性能参数调优[通俗易懂]

tikv性能参数调优[通俗易懂]tiKV最底层使用的是RocksDB(tidb3.0版本中将使用tian存储引擎)做为持久化存储,所以TiKV的很多性能相关的参数都是与RocksDB相关的。TiKV使用了两个RocksDB实例,默认RocksDB实例存储KV数据,RaftRocksDB实例(简称RaftDB)存储Raft数据。TiKV使用了RocksDB的ColumnFamil…

大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

tiKV 最底层使用的是 RocksDB(tidb3.0版本中将使用tian存储引擎) 做为持久化存储,所以 TiKV 的很多性能相关的参数都是与 RocksDB 相关的。TiKV 使用了两个 RocksDB 实例,默认 RocksDB 实例存储 KV 数据,Raft RocksDB 实例(简称 RaftDB)存储 Raft 数据。

TiKV 使用了 RocksDB 的 Column Families (CF) 特性。

  • 默认 RocksDB 实例将 KV 数据存储在内部的 defaultwrite 和 lock 3 个 CF 内。

    • default CF 存储的是真正的数据,与其对应的参数位于 [rocksdb.defaultcf] 项中;
    • write CF 存储的是数据的版本信息 (MVCC) 以及索引相关的数据,相关的参数位于 [rocksdb.writecf] 项中;
    • lock CF 存储的是锁信息,系统使用默认参数。
  • Raft RocksDB 实例存储 Raft log。

    • default CF 主要存储的是 Raft log,与其对应的参数位于 [raftdb.defaultcf] 项中。

每个 CF 都有单独的 block-cache,用于缓存数据块,加速 RocksDB 的读取速度,block-cache 的大小通过参数 block-cache-size 控制,block-cache-size 越大,能够缓存的热点数据越多,对读取操作越有利,同时占用的系统内存也会越多。

每个 CF 有各自的 write-buffer,大小通过 write-buffer-size 控制

# 日志级别,可选值为:trace,debug,info,warn,error,off
log-level = "info"

[server]
# 监听地址
# addr = "127.0.0.1:20160"

# gRPC 线程池大小
# grpc-concurrency = 4
# TiKV 每个实例之间的 gRPC 连接数
# grpc-raft-conn-num = 10

# TiDB 过来的大部分读请求都会发送到 TiKV 的 Coprocessor 进行处理,该参数用于设置
# coprocessor 线程的个数,如果业务是读请求比较多,增加 coprocessor 的线程数,但应比系统的
# CPU 核数小。例如:TiKV 所在的机器有 32 core,在重读的场景下甚至可以将该参数设置为 30。在没有
# 设置该参数的情况下,TiKV 会自动将该值设置为 CPU 总核数乘以 0.8。
# end-point-concurrency = 8

# 可以给 TiKV 实例打标签,用于副本的调度
# labels = {zone = "cn-east-1", host = "118", disk = "ssd"}

[storage]
# 数据目录
# data-dir = "/tmp/tikv/store"

# 通常情况下使用默认值就可以了。在导数据的情况下建议将该参数设置为 1024000。
# scheduler-concurrency = 102400
# 该参数控制写入线程的个数,当写入操作比较频繁的时候,需要把该参数调大。使用 top -H -p tikv-pid
# 发现名称为 sched-worker-pool 的线程都特别忙,这个时候就需要将 scheduler-worker-pool-size
# 参数调大,增加写线程的个数。
# scheduler-worker-pool-size = 4

[pd]
# pd 的地址
# endpoints = ["127.0.0.1:2379","127.0.0.2:2379","127.0.0.3:2379"]

[metric]
# 将 metrics 推送给 Prometheus pushgateway 的时间间隔
interval = "15s"
# Prometheus pushgateway 的地址
address = ""
job = "tikv"

[raftstore]
# 默认为 true,表示强制将数据刷到磁盘上。如果是非金融安全级别的业务场景,建议设置成 false,
# 以便获得更高的性能。
sync-log = true

# Raft RocksDB 目录。默认值是 [storage.data-dir] 的 raft 子目录。
# 如果机器上有多块磁盘,可以将 Raft RocksDB 的数据放在不同的盘上,提高 TiKV 的性能。
# raftdb-dir = "/tmp/tikv/store/raft"

region-max-size = "384MB"
# Region 分裂阈值
region-split-size = "256MB"
# 当 Region 写入的数据量超过该阈值的时候,TiKV 会检查该 Region 是否需要分裂。为了减少检查过程
# 中扫描数据的成本,数据过程中可以将该值设置为32MB,正常运行状态下使用默认值即可。
region-split-check-diff = "32MB"

[rocksdb]
# RocksDB 进行后台任务的最大线程数,后台任务包括 compaction 和 flush。具体 RocksDB 为什么需要进行 compaction,
# 请参考 RocksDB 的相关资料。在写流量比较大的时候(例如导数据),建议开启更多的线程,
# 但应小于 CPU 的核数。例如在导数据的时候,32 核 CPU 的机器,可以设置成 28。
# max-background-jobs = 8

# RocksDB 能够打开的最大文件句柄数。
# max-open-files = 40960

# RocksDB MANIFEST 文件的大小限制.
# 更详细的信息请参考:https://github.com/facebook/rocksdb/wiki/MANIFEST
max-manifest-file-size = "20MB"

# RocksDB write-ahead logs 目录。如果机器上有两块盘,可以将 RocksDB 的数据和 WAL 日志放在
# 不同的盘上,提高 TiKV 的性能。
# wal-dir = "/tmp/tikv/store"

# 下面两个参数用于怎样处理 RocksDB 归档 WAL。
# 更多详细信息请参考:https://github.com/facebook/rocksdb/wiki/How-to-persist-in-memory-RocksDB-database%3F
# wal-ttl-seconds = 0
# wal-size-limit = 0

# RocksDB WAL 日志的最大总大小,通常情况下使用默认值就可以了。
# max-total-wal-size = "4GB"

# 可以通过该参数打开或者关闭 RocksDB 的统计信息。
# enable-statistics = true

# 开启 RocksDB compaction 过程中的预读功能,如果使用的是机械磁盘,建议该值至少为2MB。
# compaction-readahead-size = "2MB"

[rocksdb.defaultcf]
# 数据块大小。RocksDB 是按照 block 为单元对数据进行压缩的,同时 block 也是缓存在 block-cache
# 中的最小单元(类似其他数据库的 page 概念)。
block-size = "64KB"

# RocksDB 每一层数据的压缩方式,可选的值为:no,snappy,zlib,bzip2,lz4,lz4hc,zstd。
# no:no:lz4:lz4:lz4:zstd:zstd 表示 level0 和 level1 不压缩,level2 到 level4 采用 lz4 压缩算法,
# level5 和 level6 采用 zstd 压缩算法,。
# no 表示没有压缩,lz4 是速度和压缩比较为中庸的压缩算法,zlib 的压缩比很高,对存储空间比较友
# 好,但是压缩速度比较慢,压缩的时候需要占用较多的 CPU 资源。不同的机器需要根据 CPU 以及 I/O 资
# 源情况来配置怎样的压缩方式。例如:如果采用的压缩方式为"no:no:lz4:lz4:lz4:zstd:zstd",在大量
# 写入数据的情况下(导数据),发现系统的 I/O 压力很大(使用 iostat 发现 %util 持续 100% 或者使
# 用 top 命令发现 iowait 特别多),而 CPU 的资源还比较充裕,这个时候可以考虑将 level0 和
# level1 开启压缩,用 CPU 资源换取 I/O 资源。如果采用的压缩方式
# 为"no:no:lz4:lz4:lz4:zstd:zstd",在大量写入数据的情况下,发现系统的 I/O 压力不大,但是 CPU
# 资源已经吃光了,top -H 发现有大量的 bg 开头的线程(RocksDB 的 compaction 线程)在运行,这
# 个时候可以考虑用 I/O 资源换取 CPU 资源,将压缩方式改成"no:no:no:lz4:lz4:zstd:zstd"。总之,目
# 的是为了最大限度地利用系统的现有资源,使 TiKV 的性能在现有的资源情况下充分发挥。
compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]

# RocksDB memtable 的大小。
write-buffer-size = "128MB"

# 最多允许几个 memtable 存在。写入到 RocksDB 的数据首先会记录到 WAL 日志里面,然后会插入到
# memtable 里面,当 memtable 的大小到达了 write-buffer-size 限定的大小的时候,当前的
# memtable 会变成只读的,然后生成一个新的 memtable 接收新的写入。只读的 memtable 会被
# RocksDB 的 flush 线程(max-background-flushes 参数能够控制 flush 线程的最大个数)
# flush 到磁盘,成为 level0 的一个 sst 文件。当 flush 线程忙不过来,导致等待 flush 到磁盘的
# memtable 的数量到达 max-write-buffer-number 限定的个数的时候,RocksDB 会将新的写入
# stall 住,stall 是 RocksDB 的一种流控机制。在导数据的时候可以将 max-write-buffer-number
# 的值设置的更大一点,例如 10max-write-buffer-number = 5

# 当 level0 的 sst 文件个数到达 level0-slowdown-writes-trigger 指定的限度的时候,
# RocksDB 会尝试减慢写入的速度。因为 level0 的 sst 太多会导致 RocksDB 的读放大上升。
# level0-slowdown-writes-trigger 和 level0-stop-writes-trigger 是 RocksDB 进行流控的
# 另一个表现。当 level0 的 sst 的文件个数到达 4(默认值),level0 的 sst 文件会和 level1 中
# 有 overlap 的 sst 文件进行 compaction,缓解读放大的问题。
level0-slowdown-writes-trigger = 20

# 当 level0 的 sst 文件个数到达 level0-stop-writes-trigger 指定的限度的时候,RocksDB 会
# stall 住新的写入。
level0-stop-writes-trigger = 36

# 当 level1 的数据量大小达到 max-bytes-for-level-base 限定的值的时候,会触发 level1 的
# sst 和 level2 种有 overlap 的 sst 进行 compaction。
# 黄金定律:max-bytes-for-level-base 的设置的第一参考原则就是保证和 level0 的数据量大致相
# 等,这样能够减少不必要的 compaction。例如压缩方式为"no:no:lz4:lz4:lz4:lz4:lz4",那么
# max-bytes-for-level-base 的值应该是 write-buffer-size 的大小乘以 4,因为 level0 和
# level1 都没有压缩,而且 level0 触发 compaction 的条件是 sst 的个数到达 4(默认值)。在
# level0 和 level1 都采取了压缩的情况下,就需要分析下 RocksDB 的日志,看一个 memtable 的压
# 缩成一个 sst 文件的大小大概是多少,例如 32MB,那么 max-bytes-for-level-base 的建议值就应
# 该是 32MB * 4 = 128MB。
max-bytes-for-level-base = "512MB"

# sst 文件的大小。level0 的 sst 文件的大小受 write-buffer-size 和 level0 采用的压缩算法的
# 影响,target-file-size-base 参数用于控制 level1-level6 单个 sst 文件的大小。
target-file-size-base = "32MB"

# 在不配置该参数的情况下,TiKV 会将该值设置为系统总内存量的 40%。如果需要在单个物理机上部署多个
# TiKV 节点,需要显式配置该参数,否则 TiKV 容易出现 OOM 的问题。
# block-cache-size = "1GB"

[rocksdb.writecf]
# 保持和 rocksdb.defaultcf.compression-per-level 一致。
compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]

# 保持和 rocksdb.defaultcf.write-buffer-size 一致。
write-buffer-size = "128MB"
max-write-buffer-number = 5
min-write-buffer-number-to-merge = 1

# 保持和 rocksdb.defaultcf.max-bytes-for-level-base 一致。
max-bytes-for-level-base = "512MB"
target-file-size-base = "32MB"

# 在不配置该参数的情况下,TiKV 会将该值设置为系统总内存量的 15%。如果需要在单个物理机上部署多个
# TiKV 节点,需要显式配置该参数。版本信息(MVCC)相关的数据以及索引相关的数据都记录在 write 这
# 个 CF 里面,如果业务的场景下单表索引较多,可以将该参数设置的更大一点。
# block-cache-size = "256MB"

[raftdb]
# RaftDB 能够打开的最大文件句柄数。
# max-open-files = 40960

# 可以通过该参数打开或者关闭 RaftDB 的统计信息。
# enable-statistics = true

# 开启 RaftDB compaction 过程中的预读功能,如果使用的是机械磁盘,建议该值至少为2MB。
# compaction-readahead-size = "2MB"

[raftdb.defaultcf]
# 保持和 rocksdb.defaultcf.compression-per-level 一致。
compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]

# 保持和 rocksdb.defaultcf.write-buffer-size 一致。
write-buffer-size = "128MB"
max-write-buffer-number = 5
min-write-buffer-number-to-merge = 1

# 保持和 rocksdb.defaultcf.max-bytes-for-level-base 一致。
max-bytes-for-level-base = "512MB"
target-file-size-base = "32MB"

# 通常配置在 256MB 到 2GB 之间,通常情况下使用默认值就可以了,但如果系统资源比较充足可以适当调大点。
block-cache-size = "256MB"

tikv内存使用情况

  1. TiKV 在处理大的查询的时候(例如 select * from ...)会读取数据然后在内存中生成对应的数据结构返回给 TiDB,这个过程中 TiKV 会占用一部分内存

转载于:https://www.cnblogs.com/FengGeBlog/p/10278368.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/190173.html原文链接:https://javaforall.net

(0)
上一篇 2026年2月26日 上午7:01
下一篇 2026年2月26日 上午7:43


相关推荐

  • SPU和SKU概念

    SPU和SKU概念SPU 介绍 SPU StandardProd 标准产品单位 概念 SPU 是商品信息聚合的最小单位 是一组可复用 易检索的标准化信息的集合 该集合描述了一个产品的特性 通俗点讲就是属性值 特性相同的货品就可以称为一个 SPU 举例 例如绿色的 IPhone12 就是一个 SPU 与商家 颜色 款式 套餐等都无关 SKU 介绍 SKU stockkeeping 库存量单位 概念 SKU 即库存进出计量的单位 可以是以件 盒 托盘等为单位 SKU 是物理上不可分割的最小

    2026年3月26日
    2
  • C++之指针使用

    一指针和数组对比C++/C程序中,指针和数组在不少地方可以相互替换着用,让人产生一种错觉,以为两者是等价的。数组要么在静态存储区被创建(如全局数组),要么在栈上被创建。数组名对应着(而不是指向)一

    2021年12月19日
    52
  • SVN服务器部署「建议收藏」

    SVN服务器部署「建议收藏」1,关闭防火墙或者开放对应端口3690,2,Yum下载安装subversion检查SVN是否安装成功svnserve–version3,建立SVN版本库3.1因为大磁盘挂载在/home下,所以我是在/home下创建的版本库,mkdir/home/svn创建一个文件夹(所有项目库都在此目录下创建)3.2创建svn版本库svnadmincreate/home/svn/liangz_artliangz_art才是项目版本库的名字,后面开发人员checkout时就要用这个名称,项

    2022年7月19日
    21
  • 数据库隔离级别实现原理[通俗易懂]

    数据库隔离级别实现原理[通俗易懂]昨晚和以为前辈聊天,聊到Mysql的引擎innodb默认的事务隔离级别是REPEATABLEREAD(可重复读);在Oracle中默认的事务隔离级别是提交读(readcommitted)。那么,问题来了,在Mysql中的隔离级别是怎么实现的呢?关于数据库数据隔离级别在之前的博客中总结过:https://blog.csdn.net/qq_34417408/article/details/79…

    2022年5月9日
    66
  • 图形推理专项突破训练1000题及详解_行测图形推理题怎么搜答案

    图形推理专项突破训练1000题及详解_行测图形推理题怎么搜答案图形推理是很常见的推理题型,在做这类型题目的时候,同学们出现了”两极分化”的特征,有的同学很快找到规律,做出了题目,有的同学却一直看着第一题”百思不得其解”。出现这样的情况,其根本原因在于图形推理是技巧性很强的题目,如果知道技巧,可以很快知道出题人考查的重点,从而快速联想到可会考的规律。下面我们一起来看一下图形推理的规(tao)律(lu):第一层:相似性相异(图形差距很大)→数量关系相同(图形差距…

    2025年10月17日
    5
  • NSSM使用说明

    NSSM使用说明1、说明NSSM是一个服务封装程序,它可以将普通exe程序封装成服务,使之像windows服务一样运行。同类型的工具还有微软自己的srvany,不过nssm更加简单易用,并且功能强大。它的特点如下:支持普通exe程序(控制台程序或者带界面的Windows程序都可以)安装简单,修改方便可以重定向输出(并且支持Rotation)可以自动守护封装了的…

    2025年8月14日
    5

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号