使用unordered_write调优RocksDB写性能

文章探讨了在RocksDB服务中,启用unordered_write=true的策略如何提高写入吞吐量,尽管牺牲了一致性。通过分析堆栈和CPU使用情况,发现这一优化通过提早释放写入队列领导权,显著减少了CPU耗损并提高了4倍性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在使用rocksdb存储的服务中,我们发现QPS在4w/s就怎么调整都上不去了,写性能受到了某种限制。为什么呢?下图描述了rocksdb写入的流程。我们发现 unordered_write = true可以提高写入吞吐量。

image-20220510132626787.png

  1. rocksdb的数据正常写入流程是,多个线程形成一个queue(也叫write_group),不在这个queue线程的或者后面来的线程就等待,等待上一个queue所有所有数据写入完成了后,后面的线程也会组织成一个新的queue接着写入
  2. 一个queue的写入分二步,写wal和写mem,默认都统一由当时queue的lead 线程来完成,并且这二步是串行的。因为非当前queue的其它写入线程要一直等待当前queue的全部写入完成才开始执行,导致吞吐量上不去。
  3. unordered_write= true 的优化思路是当前queue的leader写入wal完成后,不用接着写mem而是首先通知当前queue的其它线程让它们自行写入mem,然后通知非当前queue的其它线程,这样其它线程会立马形成新的queue继续写入,新的queue就节省了等待上一个queue写mem的时间!这里做的好处当然可以大大提高吞吐量,但坏处是以前数据的一致性试图就无法保证。因为当前queue的返回了,这个时候mem才开始写,并没有写入完成,这个时候来读就可能读到老的数据。 简单地将unordered_write改为true,我们发现很QPS迅速飙升到10w/s+。这给了我们很大的惊喜。

unordered_write改为true为什么有效

我们对比两个参数的堆栈来看看到底有什么魔法:下图是我在相关函数加入跟踪代码,不同参数下的堆栈:

image-20220510140745695.png

我们发现在unordered_write改为true后,write_thread.cc:636 ::ExitAsBatchGroupLeader被及早地调用,此时写memtable是其他线程都可以去写,注意,此时rocksdb的memtable是并发skiplist,在unordered_write改为true后调用的自选CAS版本的skiplist,效果显著。 我们进一步使用pref来看看调用CPU耗损:

unordered_write为false

image-20220510191607750.png

unordered_write为true

image-20220510170629090.png

我们看到基于提早释放,write_thread.cc:636 ::ExitAsBatchGroupLeader的效果:unordered_write = true的CPU耗损,对比下一张图,CPU占比减少了1倍之多,而还获取了4倍的写入性能。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值