麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践
1690
2023-05-06
教你玩转MyRocks/RocksDB—STATISTICS与后台线程篇
0. Intro
在facebook的MySQL版本(以下称为MyRocks)中,RocksDB是可选的存储引擎。相比于InnoDB引擎,RocksDB的一个重要的优势是它使用更少的磁盘空间。在生产系统中,特别是用户数在亿级以上的互联网应用,磁盘空间是其中比较大的成本之一,而能够使用更少的磁盘空间的RocksDB无疑是具有吸引力的。然而在生产系统中使用新的存储引擎自然有它的潜在风险,除了通过外部的各种benchmark工具测试得到各种性能数据,全方位的内部指标可以帮助我们真正了解数据库内部正在发生的事情,对于性能调优和开发都具有指导意义。而MyRocks通过SHOW ENGINE ROCKSDB STATUS和多个INFORMATION_SCHEMA表等方式提供了较为全面的内部指标。
本文将介绍SHOW ENGINE ROCKSDB STATUS中关于STATISTICS统计值与后台线程的实现原理。在了解实现原理的基础上,便可以较容易地通过扩展功能使它更好地为我们服务。
调用SHOW ENGINE ROCKSDB STATUS指令会返回多行数据,其中包括:
调用SHOW ENGINE ROCKSDB STATUS会返回若干行数据,然而这些数据并非事先存储于某个表格中,而是通过调用位于rocksdb/ha_rocksdb.cc文件中的rocksdb_show_status函数将内存中对应的数值进行规整返回给用户。
1. STATISTICS
根据RocksDB官方相关文档介绍STATISTICS,开启STATISTICS会增加增加5%-10%额外开销。
STATISTICS统计值记录着RocksDB引擎所有线程的所有操作的各类count/time的累加。RocksDB引擎在它的各类操作如Put/Get/Delete中的代码都设立了很多埋点。
以函数GetEntryFromCache为例,它的作用是返回可用的block cache。特别地,可以看到statistics是GetEntryFromCache和block_cache->Lookup的一个参数。没错,就是靠着statistics这个参数它到处收集数据。
当有可用的block cache时,调用了三次RecordTick为其中三个统计值增加计数;没有可用的block cache,同样也为BLOCK_CACHE_MISS和block_cache_miss_ticker增加计数。
Cache::Handle* GetEntryFromCache(Cache* block_cache, const Slice& key, Tickers block_cache_miss_ticker, Tickers block_cache_hit_ticker, Statistics* statistics) { auto cache_handle = block_cache->Lookup(key, statistics); if (cache_handle != nullptr) { PERF_COUNTER_ADD(block_cache_hit_count, 1); // overall cache hit RecordTick(statistics, BLOCK_CACHE_HIT); // total bytes read from cache RecordTick(statistics, BLOCK_CACHE_BYTES_READ, block_cache->GetUsage(cache_handle)); // block-type specific cache hit RecordTick(statistics, block_cache_hit_ticker); } else { // overall cache miss RecordTick(statistics, BLOCK_CACHE_MISS); // block-type specific cache miss RecordTick(statistics, block_cache_miss_ticker); } return cache_handle; }
1.1 RocksDB的STATISTICS接口
使用STATISTICS的方法也很简单。
它的头文件位于:
include/rocksdb/statistics.h monitoring/statistics.h
使用方法:
Options options; options.statistics = rocksdb::CreateDBStatistics();
可选统计级别:
kExceptDetailedTimers: 除去mutex等待和压缩的计时kExceptTimeForMutex: 除去mutex等待的计时kAll: 所有
数据统计类型分成两种:
ticker:计数,类型是64位无符号整型。用于度量counters (e.g. “rocksdb.block.cache.hit”), cumulative bytes (e.g. “rocksdb.bytes.written”) 或者 time (e.g. “rocksdb.l0.slowdown.micros”)。histogram:统计数据的统计分布,包括***值、最小值、平均值、中位数、标准差。
统计函数的接口:
MeasureTime:函数名有歧义。实际上是把value记录到histogram中。RecordTick:累加ticker。
获取结果的接口:
Statistics::getTickerCount:指定ticker type获得count。Statistics::histogramData:指定Histograms type,返回一个HistogramData结构体,成员是统计值,包括***值、最小值、平均值、中位数、标准差。Statistics::getHistogramString:指定Histograms type,返回直方图可读的字符串。Statistics::ToString():返回可读的字符串,包括所有的ticker和histogram。
1.2 RocksDB的STATISTICS实现
RocksDB实现了StatisticsImpl类,继承了Statistics的接口。
主要接口:getTickerCounthistogramDatagetHistogramStringgetAndResetTickerCountrecordTickmeasureTimeToString
成员变量:
TickerInfo tickers_[INTERNAL_TICKER_ENUM_MAX];HistogramInfo histograms_[INTERNAL_HISTOGRAM_ENUM_MAX];
这里的TickerInfo和HistogramInfo类型的数据结构是相似的:一个线程局部的counter或者time;加上一个非线程局部的统计值用来累加counter或者time。
TickerInfo类型包含两个参数:
ThreadLocalPtr类型(真实类型ThreadTickerInfo)的thread_value,包含:
整型类型的value指向merged_sum的指针整型类型的merged_sumHistogreamInfo类型包含两个参数:
ThreadLocalPtr类型(真实类型ThreadHistogramInfo)的thread_value,包含:
HistogramImpl类型的value指向merged_hist的指针指向merge_lock的指针HistogramImpl类型的merged_histMutex类型的merge_lock
事实上,STATISTICS相关实现是比较巧妙的,也是使用STATISTICS仅增加5%-10%的关键。为了避免线程间共享数据导致CPU的cache频繁失效,merged_sum和merged_hist初始化时都是空的,而且当且仅当线程退出时,才调用mergeThreadValue函数将TickerInfo和HistogreamInfo中的线程局部变量累加到merged_sum和merged_hist。
1.3 MyRocks的使用
rocksdb_stats = rocksdb::CreateDBStatistics(); rocksdb_db_options->statistics = rocksdb_stats;
除了使用所有RocksDB引擎层的统计,MyRocks还通过定义了
在rocksdb_show_status函数中,输出Statistics统计的过程如下:
如果定义rocksdb_stats,则调用rocksdb_stats->ToString()将统计值转化为可读的字符串;
假如定义了is-write-stopped或者actual-delayed-write-rate等Property变量,同样会将它们输出。
2 后台线程
通过调用SHOW ENGINE ROCKSDB STATUS可以得到与BG_THREADS相关结果,它的输出结果类似于:
Type: BG_THREADS Name: 140173379593984 Status: thread_type: Low Pri## cf_name: default operation_type: Compaction operation_stage: CompactionJob::ProcessKeyValueCompaction elapsed_time_ms: 6172.244 ms BaseInputLevel: 0 BytesRead: 992806363 BytesWritten: 992071408 IsDeletion: 0 IsManual: 0 IsTrivialMove: 0 JobID: 1936 OutputLevel: 5 TotalInputBytes: 1586832446 state_type:
可以看到较多的信息量:这个线程正在进行Compaction,处于CompactionJob::ProcessKeyValueCompaction阶段,已经耗时6172.244 ms,读取的字节数为992806363,写出的字节数为992071408。然而并不包括可能感兴趣的正在进行Compaction的源文件和目标文件等信息。正如文章开头提到的,了解实现原理能够使我们更好地进行扩展。
2.1 thread status的接口与实现
MyRocks中的SHOW ENGINE ROCKSDB STATUS指令展示BG_THREAD的机制使用了RocksDB中关于thread status的接口。
它的头文件位于:
include/rocksdb/env.h include/rocksdb/thread_status.h util/thread_operation.h monitoring/thread_status_updater.h monitoring/thread_status_util.h
关键类:
ThreadStatusUpdater:存储了各自后台线程的状态和所有后台线程状态的指针。ThreadStatusUtil:该类只有静态变量和静态方法,推荐通过该类的方法去更新ThreadStatusUpdater中的状态。
使用方法:
将该线程的统计加入ThreadStatusUpdater:调用ThreadStatusUtil::RegisterThread将该线程的统计从ThreadStatusUpdater删除:调用ThreadStatusUtil::UnregisterThread其他修改thread status的函数:见monitoring/thread_status_util.h
通过调用env的GetThreadList()函数可以获得当前后台线程的状态,状态的状态值存放于一个vector中。将其中的内容展现出来,类似于下图:
enum CompactionPropertyType : int { COMPACTION_JOB_ID = 0, COMPACTION_INPUT_OUTPUT_LEVEL, COMPACTION_PROP_FLAGS, COMPACTION_TOTAL_INPUT_BYTES, COMPACTION_BYTES_READ, COMPACTION_BYTES_WRITTEN, NUM_COMPACTION_PROPERTIES };
flush特有的状态值有:
enum FlushPropertyType : int { FLUSH_JOB_ID = 0, FLUSH_BYTES_MEMTABLES, FLUSH_BYTES_WRITTEN, NUM_FLUSH_PROPERTIES };
2.2 MyRocks/RocksDB的使用
在RocksDB的线程池实现中,每一个启动的后台线程都会通过调用ThreadStatusUtil::RegisterThread加入被观测的后台线程的集合中。
ThreadPoolImpl::Impl::StartBGThreads-->BGThreadWrapper-->ThreadStatusUtil::RegisterThread
在rocksdb_show_status函数中,输出BG_THREAD的过程如下:
通过调用GetThreadList(&thread_list)获得所有后台线程的ThreadStatus的集合。通过遍历ThreadStatus的集合将每一个后台线程的状态依次输出。
3. 小结
本文章介绍了SHOW ENGINE ROCKSDB STATUS指令中关于STATISTICS与BG_THREAD的相关内容。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。