Xin.Zh

发生这种问题的时候，通过如下方式解决： step1：提前监控 pika 日志，当磁盘快满的时候，pika 就会打印日志，可以提前删除磁盘上上无用的数据【如日志】，以解决问题； step2：如果磁盘已经满溢，此时 Pika 会进入自我保护状态，请先删除磁盘上其他应用的数据，清空磁盘后，向 Pika 发送 diskrecovery 命令，此时磁盘会恢复数据写； step3：平时尝试做配置低峰期及时做 compact 及时清除碎片化数据的操作。

相应 PR https://github.com/Qihoo360/blackwidow/pull/17 在 seek 的时候指定 iterator range 上下边界，但有问题：  里面 list RedisLists::LRem 函数这个地方，read_options 这里他设置值了，但是 "rocksdb::Iterator* iter = db_->NewIterator(default_read_options_, handles_[1]); " 这里使用的还是 default_read_options_ 另外，这个 PR 已经 2022 年合并了，但是 Pika 仓库...

> reassgin to me thank you.

大 key、慢查询与数据 compaction bigo denghao：背景是这样子的 我们线上经常有业务偶尔zremrangebyrank一个大key 然后导致命令越来越慢 我在想有没有别的优化方案，small compaction如果常开的话会有一些额外的开销，所以我加了一个新命令 compactrange $type $start $end，在review代码和测试的时候发现了这个代码。  想必一定是遇到了同样的问题。在命令里判断rocksdb迭代的时间 hard code 超过1秒 就对这个key执行compact。 水哥：这个只能勤compact，没有好的解法。之前考虑过deleterange降低tombstome，但考虑rocksdb可能有bug没敢用，目前的zset set delete放大是比较恐怖的，本身就起码三倍放大了，如果key本身数据还多，scan cpu浪费会比较严重，如果blobcache能抗污染cache住一部分也能降低开销。 简单方法其实就是统计key然后compact，你觉得pika哪个统计的大锁太离谱可以改成小的/原子计数/threadlocal都行。勤compact，然后compact的带宽限制一下，基本对cpu没啥影响。对其他查没啥影响。 denghao：加了 打算改下锁再把命令也暴露出来。 水哥：scan性能退化两个角度 tombstone太多 这个只能compact 文件太多...

读写锁：不公平，默认写优先，有可能在大量写的情况下，把读饿死

这是正常的建联日志

> > 这是正常的建联日志 > > pika 日志有设置保留时间么？还是会永久保存？如果没有保留时间的话磁盘很快就满了 这个需要你关注下为何不断在创建新连接，pika 这边一般都是长连接，这个日志我们觉得是有意义的。

https://wanghenshui.github.io/2020/07/14/reduce-lock.html

lcy 下周继续给 wxr 复现该 issue

@sunjiajun