以一個三節點叢集為例，我重新啟動了第一個節點上的所有 ceph-osd。

圖片來源：Bigstack CubeCOS

10 分鐘後，我仍然看到上述的 HEALTH_WARN 狀態。系統提示 14 個 osd 異常並且 pgs 不足。這個警告是合理的，因為該存儲叢集配置為三重複製並以主機為故障域。當三個節點中的一個節點的 osd 異常時，ceph 無法完成第三個副本，導致 pgs 不足。這個問題會在更大規模的叢集（更多節點）中惡化，因為 ceph 會開始在另一個節點上建立第三個副本。這會完全浪費磁碟的 I/O，因為當這 14 個 osd 恢復正常後，ceph 會意識到有 4 個副本，然後還會額外處理刪除多餘的副本。這些不必要的磁碟活動不僅縮短了磁碟的壽命，尤其是 SSD，還增加了 osd 進程的記憶體使用量。這還不是全部。請注意，這是一個運行中的叢集，ceph 仍在處理存儲請求。ceph 會繼續寫入數據並將 pgs 分配給剩餘的 osd。這意味著，一旦這 14 個 osd 重新加入叢集，它們必須同步並重新平衡 pgs。顯然，越早讓 osd 恢復正常狀態，對整個存儲叢集的各方面都越有利。

# systemctl restart ceph-osd@7
# /usr/bin/ceph-osd -d --cluster ceph --id 7 --setuser ceph --setgroup ceph --debug_bluefs 10 --debug_bluestore 10

有大量的訊息，但總體來說，情況看起來還算正常，直到出現以下情況：

bluestore(/var/lib/ceph/osd/ceph-7) _open_db_and_around read-only:0 repair:0

在這步驟之後，發現大量的讀取活動發生在 rocksdb 上。這從磁碟的 iostat 輸出中得到了證實。經過一番搜尋和無頭實驗，我觀察到一些 osd 恢復的速度似乎比其他的快。線索指向 bluestore rocksdb 中過多的讀取操作。那麼，儲存在那裡的最大數據是什麼呢？

圖片來源：Bigstack CubeCOS

當我們檢查 ceph 磁碟的空間使用情況時，一個看起來可疑的欄位是 META。一些 osd 的 META 大小相對較小（以 MB 計算），而大多數其他 osd 則在 GB 級別。結果發現，META 大小越大，osd 完成啟動所需的時間就越長。這與我們觀察到的情況相符，因為 META 資料儲存在 bluestore rocksdb 中。

幸運的是，ceph 提供了一個工具來減少 META 資料的大小。

圖片來源：Bigstack CubeCOS