ceph osd slow io (一):对象存储index osd 的rocksdb性能下降

概述

在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
相关推荐
馨谙1 小时前
标题:Linux 系统中的“保险库管理员”:深入浅出理解 /etc/shadow 文件
linux·运维·服务器
wadesir2 小时前
云服务器与传统服务器租用的核心差异解析(云服务器与服务器租用之间的区别在哪里?)
运维·服务器
凯子坚持 c2 小时前
Docker 深度解析:从虚拟化到新一代应用构建、运行与交付
运维·docker·容器
风吹落叶花飘荡2 小时前
启用服务器登录失败处理与超时自动退出功能
运维·服务器
乌萨奇也要立志学C++3 小时前
【Linux】基础IO(一)Linux 文件操作从入门到实践:系统调用、文件描述符、重定向,为自定义Shell添加重定向
linux·运维·chrome
嵌入式郑工8 小时前
LINUX驱动开发: 设备和驱动是怎么匹配的?
linux·运维·服务器
郭式云源生法则9 小时前
归档及压缩、重定向与管道操作和综合使用,find精确查找、find处理查找结果、vim高级使用、vimdiff多文件使用
linux·运维·服务器
getExpectObject()9 小时前
【jenkins】构建安卓
运维·jenkins
小池先生10 小时前
服务请求出现偶发超时问题,经查服务本身没问题,问题出现在nginx转发。
运维·服务器·nginx
java_logo10 小时前
vllm-openai Docker 部署手册
运维·人工智能·docker·ai·容器