TiDB调研手记1 -- TiKV的统计信息1

猿的话 2021-04-20

2956

点击蓝字关注我们

前言

RocksDB是TiKV的底层存储，所以在使用TiDB集群的时候，我们可以在TiKV的node上看到一些RocksDB的影子，同时，深入了解LSM-Tree，对于我们优化TiKV，具有很大的帮助。根据TiKV的统计信息，能更清楚了解到集群运行情况，便于问题定位及调优。

RocksDB的影子

TiKV的数据目录如下，“db”为其数据文件目录，由于tikv底层为RocksDB，所以其数据文件为sst（Sorted String Table）的许多个数据文件:

RocksDB 作为 TiKV 的核心存储引擎，用于存储 Raft 日志以及用户数据。每个 TiKV 实例中有两个 RocksDB 实例，一个用于存储 Raft 日志（通常被称为 raftdb），另一个用于存储用户数据以及 MVCC 信息（通常被称为 kvdb）。

使用hexdump查看sst文件的十六进制情况：

 hexdump -C 004357.sst

可以看到，解析的字符串中，出现了形如“rocksdb”、“leveldb”的关键字。

本文由此出发，根据TiKV的日志信息，分析其统计信息，为今后的架构升级、以及性能优化做一些准备。

TiKV配置信息

在TiKV的数据目录下，可以看到OPTIONS-**的文件，则为存储层参数配置相关的信息，其中的内容为：

（在部署时，我们可以根据业务的需要，按照官方文档进行配置的调整：https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file）

[CFOptions "raft"]
  sample_for_compression=0
  compaction_pri=ByCompensatedSize
  merge_operator=nullptr
  compaction_filter_factory=nullptr
  memtable_factory=DoublySkipListFactory
  memtable_insert_with_hint_prefix_extractor=nullptr
  comparator=leveldb.BytewiseComparator
  target_file_size_base=8388608
  max_sequential_skip_in_iterations=8
  compaction_style=kCompactionStyleLevel
  max_bytes_for_level_base=134217728
  bloom_locality=0
  write_buffer_size=134217728
  ...
  ...


  [TableOptions/BlockBasedTable "raft"]
  pin_top_level_index_and_filter=true
  enable_index_compression=true
  read_amp_bytes_per_bit=8589934592
  format_version=2
  block_align=false
  metadata_block_size=4096
  block_size_deviation=10
  partition_filters=false
  block_size=16384
  ...
  ...

例如“compaction_pri”参数，可以在文档中看到介绍：

关于TiKV的配置优化，后续根据实际的使用情况进行分解介绍。

TiKV的统计信息

统计信息的好处在于，除了可以判断整个集群的健康状态外，在工作中，更多的是根据统计信息，进行性能的优化，说到优化，通常为以下方面：

根据系统情况优化SQL
根据业务情况调整集群配置
调整各个组件的CPU、内存、磁盘、网络等配置，降低硬件资源对于数据库的影响

统计信息分类

DB Stats

参考：https://www.jianshu.com/p/ddf652aa4882

Uptime：启动到当前的时间

writes：

writes - 总的写入次数

keys - 总的写入 key 的数量
commit groups - 总的 group 提交的数量
writes per commit group - 每个 group 提交包含的写入次数
ingest - 直接 ingest 到 DB 的数量
MB/s - 写入的速度

WAL：

writes - 总的写入次数
syncs - 强制 sync 的次数
writes - 每次 sync 有多少次写入
written - 总的写入数据量
MB/s - 写入的速度

stall：

H:M:S - 总的 stall 的时间
percent - stall 的时间在总时间的比例

compaction统计

Compaction Stats的统计分为四个部分：

** Compaction Stats [default] **

** Compaction Stats [lock] **

** Compaction Stats [write] **

** Compaction Stats [raft] **

每个TiKV实例会有两个RocksDB实例，分别存储Raft日志（称为raftdb）和用户数据与MVCC信息（称为kvdb），在文件目录中，体现为“raft”目录和“db目录”：

kvdb有四个列簇：raft、lock、default、write。所以在统计信息中，可以看到Compaction Stats中分别有这四个列簇的统计信息。

由于TiKV底层为LSM树，所以在一定的周期内，会进行一次数据的合并，对于TiKV来说，以下日志标识着compaction统计的开始：

随后，TiKV将打印compaction的统计信息（此部分的统计日志信息和RocksDB相同）：

对于统计信息的解读，可以查看RocksDB的官方文档：https://rocksdb.org.cn/doc/RocksDB-Tuning-Guide.html

主要关注：

Compaction Stats：在level N和level N+1之间执行的压缩流程的压缩信息会在level N+1处（输出层）进行汇报。

Level：compactionSum 表示的是所有 level 的总和，而 Int 则表示从上一次 stats 到现在的数据。

Files：有两个值 a/b，a 用来表示当前 level 有多少文件，而 b 则用来表示当前用多少个线程正在对这层 level 做 compaction。

Size：当前 level 总共多大，单位MB。

Stalls：阻塞情况。根据LSM Tree的结构，推断stall可能发生在以下情况（在TiDB中，若出现stall，可以在日志中看到“server is busy”关键字）：

（1）需要flush到Level0的MemTable过多，此参数在TiKV中配置为：max-write-buffer-number，默认为5

（2）Level_0的sst文件过多：在TiKV中的配置为：level0-slowdown-writes-trigger，默认为20

（3）等待compaction的数据量软限制：在TiKV中为：soft-pending-compaction-bytes-limit，默认为64GB。（当超过软限制，达到硬限制hard-pending-compaction-bytes-limit时，会直接禁止写入！！！）

可以在TiDB的监控面板中，看到“server is busy”的情况：

正如MySQL一样，一些阻塞的过程是没有办法避免的，我们只能尽量的优化环境，降低阻塞的时间及影响，使其对应用无感知。

其它补充的STATISTICS

包括rocksdb的block cache情况、bloom filter情况等：

总结

日常运维中，结合TiKV提供的统计信息和TiKV的监控图表，可以方便了解集群的运行情况，并根据统计信息中的异常，例如compaction的情况、是否有stall的情况、cache命中情况等，依此去优化写入的方式，region分布，调整配置等。TiKV对于各个环节的配置（包括raftstore、storage存储相关、task相关、thread相关、region相关、rocksdb相关等等），都提供给用户，在这方面很灵活。

扫描右方二维码关注猿的话

tidb

文章转载自猿的话，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

TiDB调研手记1 -- TiKV的统计信息1

前言

RocksDB的影子

TiKV配置信息

总结

评论