從伺服器中提取數據而不會導致高磁碟 IO
我目前的診斷是存在硬體故障，要麼與硬體 RAID 控制器的記憶體有關，要麼與硬碟驅動器滿執行時所需的額外汁液有關。
嘗試更換電源，沒有骰子。嘗試實時啟動另一個作業系統，沒有骰子。高磁碟 IO 確保硬關機，無論作業系統如何。我已經確定肯定需要一台新伺服器。
然而，現在我面臨著備份驅動器內容的挑戰，而不會導致高 IO。我已經為 cgroups 配置了一個 IOps 限制，我已經玩過這個限制，看看它可以有多高而不會導致關閉。每個磁碟的結果似乎略有不同，但平均約 100 iops 似乎在崩潰之前可以工作更長時間。然而，考慮到大約有 120GB 的數據，這實際上並不可行。順便說一下，這些是 SAS 15K 驅動器。
限制 IO 似乎可行，但這是一個令人厭煩的過程，因為當伺服器關閉時我必須重新設置它。我正在使用 Runtime Live CD（Knoppix fork）將數據從驅動器複製到外部驅動器。
伺服器大約有 7 年的歷史，我碰巧沒有額外的驅動器連接器。
面對這種情況，從驅動器獲取數據的可靠方法是什麼？
僅供參考，這是幫助我設置限制 IO 的 cgroup 的連結：http: //fritshoogland.wordpress.com/2012/12/15/throttling-io-with-linux/
我自己也見過類似的東西，雖然那是幾年前的事了。
就我而言，這是記憶體問題，當複制數據時，我懷疑正在緩慢使用記憶體，直到它到達問題記憶體並且……繁榮！崩潰的電腦。記憶體測試應該足夠容易地辨識這一點，或者可能刪除一些記憶體以查看它是否可以解決或惡化問題？
如果不是，那麼我懷疑它的數據吞吐量相關，並且吞吐量只是在隱藏實際原因的同時延遲了問題。
如果數據副本導致足夠的 CPU 工作將其提升到崩潰點，是否也值得檢查 CPU 溫度？即風扇故障或散熱器滑落？減慢數據複製的速度只是減輕了足以延遲溫度上升的負擔。
最後，你不說你的磁碟是如何配置的？即RAID，或JBOD？您能否將驅動器單獨或作為一個組移動到另一台伺服器？如果它們是 RAID 驅動器，顯然不要只移動它們，除非是最後的最後手段！除非你知道你在做什麼，當然！
高溫高壓