概述
在ceph分布式集群中，经常会遇到各种非常影响业务体验的slow io。而slow io产生的可能性有很多，包括慢盘、网络、业务压力、ceph bug、缓存下刷等等。
近期遇到的一种slow io是在ceph对象存储的index pool中，因为rocksdb问题导致的slow io
对象索引与list请求
当对象存储前端进行list（调用listbucket，listobject接口）请求时，会对索引池进行访问，尤其当数据比较多时，索引池的io会激增，索引池需要遍历omapkey，从而给前端返回列表。
而omapkey实际是存在于osd rocksdb结构中（index中存的实际上是0字节的shard文件，通过对其进行listomapkey可以看到每个索引分片存的对象列表），一般来说当前端产生list请求时，只要返回这些对象列表即可。然而，底层index不仅存储需要返回给前端的对象列表，还有一些别的对象，依旧会占用omapkey，且不会返回给前端，当这些对象较多时，访问rocksdb的过程中，就需要逐个跳过这类对象（这个操作是需要时间的），从而导致整个请求时间变长，rocksdb性能下降。
一般来说这种需要跳过的，不会返回给前端list的key有两种情况会大量产生：
- 分段残留
- 大量删除
分段残留
分段残留导致的的对象，通过listomapkey可以查询到，这类对象对前端来说没有合并成完整对象，所以listobject是，看不到该对象，然而因为残留底层仍占用着omapkey空间。
因此首先要对分段残留进行定期的检查和清理。
这里展示使用s3cmd的方法。（当对象较多，s3cmd无法及时返回时，也可以通过底层对index shard进行listomapkey过滤_mul开头和解析获得分段id）
bash
s3cmd multipart s3://桶名
s3cmd abortmp 分段id大量删除
当进行了大量删除时，rocksdb由于是追加写方式更新，数据积累一定程度后才会进行compaction，清理时也是先标记，然后扔给后台compaction任务慢慢进行删除。如果前端发生大量删除，rocksdb中也会有大量被标记的对象，这类对象也会对桶遍历、前端list请求产生非常大的影响。
查询rocksdb性能
bash
ceph daemon osd.x perf查看avg_us字段，判断是否是rocksdb性能不足所导致的slow。
如果确实是，首先确认分段残留，并清理，然后确认是否近期发生过大量的删除
compact
如果确实存在上述情况，清理分段后或确认存在大量删除后，对slow 的osd进行手动compact，加快对这些有影响的key的删除回收操作。
bash
ceph tell osd.x compact