Hari ini saya membaca cara pengecekan jika Ceph lambat dari artikel cr0x.net (sumber di akhir tulisan), kemudian dari bacaan tersebut saya jadikan tulisan ini dan saya rangkum dan ringkas dan fokus ke sepuluh pengecekannya saja.

Ceph di Proxmox sering jalan mulus sampai kalian migrasi VM atau mulai backup, lalu tiba-tiba latency naik dan iowait melonjak. Penyebabnya jarang misterius, biasanya cuma salah satu dari sepuluh hal yang bisa diukur: jaringan, recovery, disk class yang ketukar, metadata BlueStore, CPU, atau CRUSH rule.

Prinsip utamanya, sebelum tuning apa pun, buktikan dulu bottleneck-nya ada di jaringan, media OSD, atau recovery. Tuning di layer yang salah cuma memperparah.

Check 1: Kesehatan cluster dan slow ops

Cek dulu apakah cluster sedang rebuild, karena recovery bisa menurunkan performa secara wajar.

ceph -s
ceph health detail

Di detail slow ops, “waiting for subops” mengarah ke jaringan atau replikasi, sedangkan “waiting for BlueStore kv commit” mengarah ke DB/WAL atau disk.

Check 2: Pastikan masalahnya di Ceph

Pastikan VM yang lambat memang ada di RBD, bukan di storage lokal.

pvesm status
rbd -p ceph-vm ls | head

Kalau cuma sebagian workload di Ceph, bandingkan dengan storage lain dulu. Kalau rbd ls saja lambat, curigai MON/MGR atau jaringan.

Check 3: Jaringan, drops, dan MTU

Jaringan adalah bus storage Ceph, jadi cek drops, retransmit, dan konsistensi MTU.

ip -s link show dev eno2
ping -c 5 -M do -s 8972 10.10.10.12
ss -ti dst 10.10.10.12 | head

RX drops tinggi dan retransmit yang naik saat beban adalah tanda jaringan, bukan tanda perlu tuning BlueStore. Kalau ping -M do gagal atau ada loss, berarti MTU tidak konsisten antar NIC, bond, bridge, dan switch.

Check 4: Public vs cluster network

Pastikan trafik replikasi tidak berebut jalur dengan trafik klien.

ceph config get mon public_network
ceph config get mon cluster_network

Kalau cluster_network kosong, recovery dan replikasi berbagi jaringan dengan klien. Pisahkan kalau kalian punya NIC atau VLAN terpisah.

Check 5: Overhead replikasi atau EC

Setiap write di pool size 3 jadi tiga write. Erasure coding hemat kapasitas tapi berat untuk write kecil.

ceph osd pool ls detail
ceph tell osd.* perf dump | head -n 20

Untuk VM dengan write random kecil, replikasi biasanya pilihan paling masuk akal. Kalau subop_latency naik relatif terhadap op_latency, curigai jaringan atau ada OSD peer yang lambat.

Check 6: Disk class dan CRUSH rule

Jangan biarkan OSD HDD nyelinap ke pool yang seharusnya full SSD.

ceph osd tree
ceph osd crush rule dump replicated_rule

Cek kolom CLASS di osd tree. Kalau rule tidak menyaring device class, HDD bisa terpilih jadi replika di pool SSD. Solusinya buat rule berbasis class.

Check 7: Penempatan DB/WAL BlueStore

OSD SSD pun bisa lambat kalau metadata (DB/WAL) ditaruh di media yang salah.

ceph-volume lvm list
ceph daemon osd.3 perf dump

lvm list menunjukkan DB/WAL tiap OSD ada di device mana, idealnya DB/WAL OSD HDD ada di SSD atau NVMe. Di perf dump, lihat bagian bluestore. Latency kv commit yang tinggi (puluhan sampai ratusan ms) berarti device DB jenuh atau terlalu banyak OSD numpuk di satu DB.

Check 8: CPU, memori, dan scheduler OSD

OSD juga butuh CPU untuk checksum dan jaringan, terutama di node hyperconverged.

ceph daemon osd.3 dump_historic_ops
top -b -n 1 | head -n 15
cat /sys/block/sdb/queue/scheduler

Operasi lebih dari satu detik tidak normal untuk SSD yang sehat. Korelasikan dengan load average, iowait, dan CPU steal. mq-deadline wajar untuk SSD, none wajar untuk NVMe.

Check 9: Recovery, backfill, dan scrub

Kerja latar belakang Ceph rebutan disk dan jaringan dengan klien, dan bisa aktif meski status HEALTH_OK.

ceph config get osd osd_recovery_max_active
ceph config get osd osd_max_backfills
ceph config set osd osd_recovery_sleep 0.1

Nilai lebih tinggi berarti recovery cepat tapi latency klien buruk, nilai lebih rendah sebaliknya. Untuk cluster kecil, jaga tetap konservatif saat jam sibuk dan kembalikan setelah insiden.

Check 10: Benchmark yang benar

Benchmark berguna kalau menjawab pertanyaan spesifik, bukan sekadar “seberapa cepat Ceph”.

rados bench -p ceph-vm 30 write --no-cleanup
rbd perf image iostat --pool ceph-vm --image vm-100-disk-0 --interval 2 --count 5

rados bench jelek berarti masalah di sisi cluster (jaringan, OSD, recovery). rados bench bagus tapi VM tetap lambat berarti masalah di sisi klien (setting RBD, pola IO). Bersihkan sisa benchmark dengan rados -p ceph-vm cleanup.

Penutup

Urutannya: tangkap kondisi saat lambat (ceph -s, ceph health detail, drops NIC, tes MTU, retransmit), pastikan rule pool tidak mencampur disk class dan network sudah terpisah, lalu perbaiki strukturnya (DB/WAL ke device yang benar, keluarkan disk outlier, atasi oversubscription). Tuning dilakukan paling akhir.

Sumber: cr0x.net, “Ceph performance on Proxmox is slow: 10 checks that actually find the bottleneck” (https://cr0x.net/en/proxmox-ceph-slow-performance-checks/).