Hiểu về SLOW_OPS trong Ceph và cách xử lý

hoanghd164
By hoanghd164
Ceph

1. SLOW_OPS trong Ceph là gì?

Trong hệ thống lưu trữ Ceph, “SLOW_OPS” là một cảnh báo xuất hiện khi một hoặc nhiều thao tác (operations) trên OSD (Object Storage Daemon) mất quá nhiều thời gian để hoàn thành. Điều này có thể ảnh hưởng đến hiệu suất của toàn bộ hệ thống, đặc biệt là đối với các ứng dụng yêu cầu độ trễ thấp.

Đây là đoạn logs của OSD được lấy tại Node Storage OSD.

2025-01-20T17:07:45.714+0000 7f3c58232640  0 log_channel(cluster) log [WRN] : 4 slow requests (by type [ 'started' : 4 ] most affected pool [ 'POOL-CEPH-01' : 4 ])
2025-01-20T17:07:46.738+0000 7f3c58232640 -1 osd.221 105256 get_health_metrics reporting 4 slow ops, oldest is osd_op(client.9863600.0:13704598371 3.199s0 3:999c446a:::638dd897-e867-4df3-901f-533513ca5149.330168.6__shadow_STORAGE%2f2025-01-14%2fINT1471235736_MTOpayment%2f20250114%2fencrypt_mto-payment_db_billing_mysql_backup_20250114_10.10.180.4.tar.gz.2~Dupq4Juaofu_JPEJdcV0I_a7glSyrrK.38_6:head [set-alloc-hint object_size 0 write_size 0,writefull 0~4194304 in=4194304b] snapc 0=[] ondisk+write+known_if_redirected+supports_pool_eio e105254)
2025-01-20T17:07:46.738+0000 7f3c58232640  0 log_channel(cluster) log [WRN] : 4 slow requests (by type [ 'started' : 4 ] most affected pool [ 'POOL-CEPH-01' : 4 ])
2025-01-20T17:07:47.690+0000 7f3c58232640 -1 osd.221 105256 get_health_metrics reporting 4 slow ops, oldest is osd_op(client.9863600.0:13704598371 3.199s0 3:999c446a:::638dd897-e867-4df3-901f-533513ca5149.330168.6__shadow_STORAGE%2f2025-01-14%2fINT1471235736_MTOpayment%2f20250114%2fencrypt_mto-payment_db_billing_mysql_backup_20250114_10.10.180.4.tar.gz.2~Dupq4Juaofu_JPEJdcV0I_a7glSyrrK.38_6:head [set-alloc-hint object_size 0 write_size 0,writefull 0~4194304 in=4194304b] snapc 0=[] ondisk+write+known_if_redirected+supports_pool_eio e105254)
2025-01-20T17:07:47.690+0000 7f3c58232640  0 log_channel(cluster) log [WRN] : 4 slow requests (by type [ 'started' : 4 ] most affected pool [ 'POOL-CEPH-01' : 4 ])
2025-01-20T17:07:48.722+0000 7f3c58232640 -1 osd.221 105256 get_health_metrics reporting 4 slow ops, oldest is osd_op(client.9863600.0:13704598371 3.199s0 3:999c446a:::638dd897-e867-4df3-901f-533513ca5149.330168.6__shadow_STORAGE%2f2025-01-14%2fINT1471235736_MTOpayment%2f20250114%2fencrypt_mto-payment_db_billing_mysql_backup_20250114_10.10.180.4.tar.gz.2~Dupq4Juaofu_JPEJdcV0I_a7glSyrrK.38_6:head [set-alloc-hint object_size 0 write_size 0,writefull 0~4194304 in=4194304b] snapc 0=[] ondisk+write+known_if_redirected+supports_pool_eio e105254)

Ví dụ chúng ta sẽ phân tích một log lỗi:

2025-01-20T17:07:46.738+0000 7f3c58232640 -1 osd.221 105256 get_health_metrics reporting 4 slow ops, oldest is osd_op(client.9863600.0:13704598371 3.199s0 3:999c446a:::638dd897-e867-4df3-901f-533513ca5149.330168.6__shadow_STORAGE%2f2025-01-14%2fINT1471235736_MTOpayment%2f20250114%2fencrypt_mto-payment_db_billing_mysql_backup_20250114_10.10.180.4.tar.gz.2~Dupq4Juaofu_JPEJdcV0I_a7glSyrrK.38_6:head [set-alloc-hint object_size 0 write_size 0,writefull 0~4194304 in=4194304b] snapc 0=[] ondisk+write+known_if_redirected+supports_pool_eio e105254)

Phân tích các thành phần quan trọng:

  • osd.221: OSD gặp vấn đề.
  • 4 slow ops: Có 4 thao tác bị chậm.
  • oldest is osd_op(… 3.199s0 …): Thao tác lâu nhất đã kéo dài 3.199 giây.
  • most affected pool [‘POOL-CEPH-01’ : 4]: Pool bị ảnh hưởng nhiều nhất là POOL-CEPH-01.
  • writefull 0~4194304 in=4194304b: Thao tác ghi dữ liệu 4MB có thể gây nghẽn.

Khi chạy lệnh ceph health detail, bạn có thể thấy lỗi như sau:

HEALTH_WARN 4 slow requests are blocked; mon osd report timeout;
SLOW_OPS 4 slow requests, oldest blocked for 3.199 sec, osd.221 has slow ops

Dưới đây là một ví dụ output của lệnh ceph pg dump pgs_brief khi có nhiều OSD gặp lỗi slow ops:

PG_STAT STATE            UP      ACTING
1.3     active+clean     [2,5,7] [2,5,7]
1.4     active+clean     [3,8,12] [3,8,12]
1.5     active+degraded  [4,6,9] [4,6,9]
1.6     active+undersized+degraded  [6,9,11] [6,9,11]
1.7     active+slow_ops  [5,7,10] [5,7,10]
1.8     active+remapped  [3,8,12] [3,8,12]
1.9     active+slow_ops  [5,9,12] [5,9,12]

🔍 Phân tích Output

  • PG 1.5, 1.6 bị degraded, ảnh hưởng OSD 4, 6, 9, 11.
  • PG 1.7, 1.9 có slow ops, ảnh hưởng OSD 5, 7, 9, 10, 12.
  • OSD bị slow ops nhiều lần:
    • 5 (xuất hiện trong PG 1.7, 1.9)
    • 9 (xuất hiện trong PG 1.5, 1.6, 1.9)
    • 12 (xuất hiện trong PG 1.4, 1.8, 1.9)

2. Nguyên nhân gây SLOW_OPS

a) OSD quá tải hoặc disk I/O chậm

  • Nếu OSD đang xử lý quá nhiều request hoặc ổ cứng bị giới hạn tốc độ, các thao tác sẽ bị chậm.
  • Đặc biệt trong hệ thống dùng HDD, tốc độ thấp hơn SSD có thể dẫn đến SLOW_OPS.

b) Backfill hoặc Recovery đang chạy

  • Nếu Ceph đang trong quá trình backfill hoặc recovery, các OSD có thể bị tải cao.
  • Kiểm tra bằng lệnh:ceph -s ceph pg dump | grep "backfill\|recover"

c) Mạng chậm hoặc mất gói

  • Kết nối mạng giữa các OSD bị chậm hoặc không ổn định có thể gây SLOW_OPS.
  • Kiểm tra bằng:ping -c 5 <osd_ip> iperf3 -c <osd_ip>

d) Thao tác ghi lớn từ client

  • Một client có thể đang ghi một file lớn (vd: backup database), gây áp lực lên OSD.
  • Ví dụ trên cho thấy file encrypt_mto-payment_db_billing_mysql_backup_20250114_10.10.180.4.tar.gz.2 có thể gây nghẽn.

3. Cách kiểm tra và khắc phục

✅ Kiểm tra hiệu suất OSD sử dụng lệnh sau:

ceph osd perf

Ví dụ output của lệnh trên.

shell> ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
434                   0                  0
627                   0                  0
961                   1                  1
960                   1                  1
959                   1                  1
958                   1                  1
957                   1                  1
956                   1                  1

Ý nghĩa các cột

  • osd – ID của OSD.
  • commit_latency(ms) – Độ trễ khi commit (ghi dữ liệu vào journal hoặc WAL).
  • apply_latency(ms) – Độ trễ khi apply (ghi dữ liệu thực tế vào backend storage).

Phân tích dữ liệu trên

  • OSD 434 và 627 có commit_latency và apply_latency bằng 0, có thể do:
    • OSD không có hoạt động ghi nào.
    • OSD bị down hoặc không nhận request.
  • Các OSD khác (961 → 956) có commit_latency và apply_latency là 1ms, tức là chúng đang hoạt động bình thường với độ trễ thấp.

Cách sử dụng scripts để kiểm tra slow ops

  • Nếu commit_latency hoặc apply_latency quá cao (VD: trên 100ms), OSD có thể bị quá tải.
  • Nếu commit_latency cao nhưng apply_latency thấp, có thể là do journal hoặc WAL chậm.
  • Nếu cả hai đều cao, có thể OSD đang gặp bottleneck về disk I/O.

🔴 OSD 5 và OSD 9 có nhiều PG bị lỗi slow ops, có thể cần loại bỏ.

Nếu OSD nào có apply_latency và commit_latency cao, nó có thể là nguyên nhân.

✅ Kiểm tra disk I/O của OSD bị chậm

iostat -x 1 -d /dev/sdX  # Thay /dev/sdX bằng disk của OSD

Nếu %util gần 100%, ổ đĩa có thể quá tải.

✅ Kiểm tra trạng thái backfill/recovery

ceph -s
ceph pg dump | grep "backfill\|recover"

Nếu có nhiều PG đang backfill hoặc recover, hệ thống có thể đang bị tải cao.

✅ Tăng ngưỡng cảnh báo tạm thời (nếu cần)

ceph config set osd osd_op_complaint_time 5  # Mặc định là 2s

Nếu hệ thống vẫn hoạt động ổn định, có thể tăng threshold để giảm cảnh báo.

✅ Điều chỉnh QoS để giảm tải

Giới hạn số lượng backfill

ceph config set osd osd_max_backfills 1

Điều chỉnh tốc độ recovery

ceph config set osd recovery_sleep 0.1

Cần bôt sung thêm quy trình các bước kiểm tra log giúp tránh quyết định quá vội vàng khi OSD chỉ gặp.

4. Script kiểm tra và loại bỏ OSD có Slow Ops

Dưới đây là một script Bash đơn giản để tự động kiểm tra và loại bỏ OSD có slow ops nặng:

#!/bin/bash

# Lấy danh sách slow ops từ ceph health
slow_ops=$(ceph health detail | grep SLOW_OPS)
if [[ -z "$slow_ops" ]]; then
    echo "✅ Không có lỗi Slow Ops."
    exit 0
fi

echo "⚠️  Phát hiện lỗi Slow Ops: "
echo "$slow_ops"

# Lấy danh sách PG bị ảnh hưởng
pgs=$(ceph pg dump pgs_brief | grep -E 'active|degraded' | awk '{print $1}')

declare -A osd_count

# Kiểm tra từng PG để tìm OSD liên quan
for pg in $pgs; do
    echo "🔍 Kiểm tra PG: $pg"
    osds=$(ceph pg $pg query | jq -r '.acting[]')
    
    for osd in $osds; do
        ((osd_count[$osd]++))
    done
done

# Tìm OSD có nhiều PG bị ảnh hưởng
max_pg=0
worst_osd=""
for osd in "${!osd_count[@]}"; do
    echo "OSD $osd liên quan đến ${osd_count[$osd]} PG bị lỗi."
    if [[ ${osd_count[$osd]} -gt $max_pg ]]; then
        max_pg=${osd_count[$osd]}
        worst_osd=$osd
    fi
done

# Nếu OSD bị ảnh hưởng quá nhiều PG, loại bỏ nó
if [[ $max_pg -ge 5 ]]; then
    echo "❌ Loại bỏ OSD $worst_osd do ảnh hưởng nhiều PG."
    ceph osd out $worst_osd
else
    echo "⚠️ OSD bị ảnh hưởng chưa quá nghiêm trọng, chưa loại bỏ."
fi

Scrips hoạt động như sau:

  • Bước 1: Kiểm tra xem có lỗi Slow Ops không.
  • Bước 2: Lấy danh sách PG bị ảnh hưởng (ceph pg dump pgs_brief).
  • Bước 3: Tìm OSD liên quan đến PG (ceph pg <pg_id> query).
  • Bước 4: Đếm số lần mỗi OSD xuất hiện trong PG bị lỗi.
  • Bước 5: Nếu một OSD bị ảnh hưởng quá nhiều (ví dụ, liên quan đến ≥5 PG bị lỗi), nó sẽ bị loại bỏ (ceph osd out <id>).

5. Kết luận

  • SLOW_OPS là cảnh báo quan trọng, có thể do OSD quá tải, backfill/recovery, mạng kém hoặc thao tác ghi lớn từ client.
  • Kiểm tra hiệu suất OSD, disk I/O và mạng để xác định nguyên nhân.
  • Điều chỉnh cấu hình Ceph hợp lý để tối ưu hóa hiệu suất.

Bài viết gần đây

spot_img

Related Stories

Ceph

Lỗi LARGE_OMAP_OBJECTS trong Ceph RGW

hoanghd164 -
Ceph

Acting Set và Up Set trong Ceph

hoanghd164 -
Ceph

Phân biệt Backfill và Recovery trong Ceph

hoanghd164 -
Ceph

Cách hành xử của Ceph khi mất kết nối OSD

hoanghd164 -
Ceph

BlueStore vs FileStore Trong Ceph

hoanghd164 -
Ceph

Cách phân bổ Object trong Object Storage và Block Storage trong Ceph

hoanghd164 -

Leave A Reply

Please enter your comment!
Please enter your name here

Đăng ký nhận thông tin bài viết qua email

© Copyright - Technew by Hà Đăng Hoàng