CEPH 集群”slow request“问题处理思路
什么是“slow request”请求
当一个请求长时间未能处理完成,ceph就会把该请求标记为慢请求(slow request
)。默认情况下,一个请求超过30
秒未完成,
就会被标记为slow request
,并打印到日志文件(默认:/var/log/ceph/ceph.log
)。请求超时时间由参数osd_op_complaint_time
指定,并可以动态的修改。另外,一个请求超过5
分钟未完成,会导致所在的OSD Daemon
程序异常退出(自杀), 自杀时间由参数osd_op_thread_suicide_timeout
指定,并可以动态的修改。
不建议将请求超时时间
osd_op_complaint_time
设置过小,以免误报;不建议将自杀时间osd_op_thread_suicide_timeout
设置过小,以免自杀后引起更大的性能抖动
可能原因及解决思路
ceph -s
或者ceph -w
检查集群状态及运行负载
- 如果状态不正常先将集群状态恢复正常(
HEALTH_OK
) - 如果正在执行backfill或recover或Deep Scrub, 可以考虑先将其中止(
ceph osd set nobackfill/norecover/nodeep-scrub
),再观察
- 如果状态不正常先将集群状态恢复正常(
检测系统负载
如果集群状态正常、负载不高,可能是系统资源不足
- 使用
dstat
查看CPU、内存、磁盘、网络使用情况,如果利用率过高(内存有Swap),估计是系统资源不足,硬件规划最好在前期做好,否则只能通过扩容缓解每个节点的压力
- 使用
优化ceph配置
如果系统资源足够,可能是集群有些配置不合理
- 存储池中pg个数太多或太少,通过
ceph osd pool set {pool} pg {num}
调整参数 - 某些配置参数设置得过大(主要是:各个*_threads参数),通过
ceph --admin-daemon {socket path} set {key} {value}
调整参数
- 存储池中pg个数太多或太少,通过
硬件检测
如果集群状态及负载都正常、系统资源也充足,就需要考虑硬件问题了
- 是否有慢盘? 通过
ceph osd perf
,iostat
等,观察及统计OSD的commit和apply延迟,wait等,找出慢盘 - 网络是否丢包,是否有error? 通过
iperf3
打流、tcpdump
抓包、查看交换机信息等排除故障
- 是否有慢盘? 通过
笔者在Ceph的运维过程中,就遇到过因为pg split
, 交换机固件故障、网络error、jbod等问题导致的慢请求故障。
以上为笔者在过往Ceph运维过程中,解决慢请求的思路,先抛砖引玉。