Ceph集群慢请求解决思路

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设置过小，以免自杀后引起更大的性能抖动

可能原因及解决思路

1. ceph -s或者 ceph -w检查集群状态及运行负载
   
   • 如果状态不正常先将集群状态恢复正常（HEALTH_OK）
   • 如果正在执行backfill或recover或Deep Scrub, 可以考虑先将其中止(ceph osd set nobackfill/norecover/nodeep-scrub)，再观察

2. 检测系统负载

   如果集群状态正常、负载不高，可能是系统资源不足

   • 使用dstat查看CPU、内存、磁盘、网络使用情况，如果利用率过高（内存有Swap），估计是系统资源不足，硬件规划最好在前期做好，否则只能通过扩容缓解每个节点的压力

3. 优化ceph配置

   如果系统资源足够，可能是集群有些配置不合理

   • 存储池中pg个数太多或太少，通过ceph osd pool set {pool} pg {num} 调整参数
   • 某些配置参数设置得过大（主要是：各个*_threads参数），通过ceph --admin-daemon {socket path} set {key} {value} 调整参数

4. 硬件检测

   如果集群状态及负载都正常、系统资源也充足，就需要考虑硬件问题了

   • 是否有慢盘？ 通过ceph osd perf，iostat等，观察及统计OSD的commit和apply延迟，wait等，找出慢盘
   • 网络是否丢包，是否有error？ 通过iperf3打流、tcpdump抓包、查看交换机信息等排除故障

笔者在Ceph的运维过程中，就遇到过因为pg split, 交换机固件故障、网络error、jbod等问题导致的慢请求故障。

以上为笔者在过往Ceph运维过程中，解决慢请求的思路，先抛砖引玉。