遇到問題：凌晨收到報警，某mongodb服務器cpu load超過8。由於沒有影響到業務，第二天一早開始查原因。
查原因：
1. 先了解該服務器上的應用有哪些
該db服務器主要應用只有mongodb。於是開始查詢mongodb日誌：
通過凌晨的日誌mongodb.log查看，有大量的慢查詢，但實際上這些表都非常小，只有幾百行數據，而且表還有索引，卻僅僅一個查詢花了60~80s，慢查詢之後的日誌顯示該節點不被其他節點檢測到（mongodb複製集形式）。
由於一個小表的查詢都需要判斷70s左右，而且mongodb部署的是複製集形式（其他的查詢節點都是正常的）可以判斷，可能是這臺db的性能方面影響了mongodb，而非mongodb本身的性能影響。
2. 於是查看凌晨有什麼任務再跑。
crontab -l 發現確實凌晨有一個任務。是一個切割日誌的腳本。大概就是把日誌cp到另一個目錄，然後將當前日誌清空，繼續記錄新的一天的日誌。
但這個日誌平時都較小，也運行了很長時間.只能試一試的看看日誌目錄
看到日誌突然就這麼大了。難道是因爲晚上cp 文件的時候導致了？
差不多判斷問題出現在 cp導致了io負載過高，進而導致了cpu load 過高。
3. 復現問題
由於該操作在夜間操作，未影響線上業務。故手動操作cp，復現問題。
cp 了一個近3g的文件， 如下圖：看到產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
跟着cpu load也 上升到10 （每一分鐘的cpu load 值）左右。
解決問題：
將較大的日誌從mongodb服務器分離出。
將小日子日誌腳本切割改爲系統logrotate切割。logrotate會在系統空閒的狀態進行操作。
可是爲什麼拷貝了一個3g的文件，就會導致cpu load 高達10. 進而導致mongodb查詢性能直線下降。
於是我們聯繫了某雲，一個普通雲盤的性能怎會如此低！
以上查問題的思路，最開始也沒有很順利。起初文件較小並沒有猜測到是日誌拷貝。查問題的時候不能以慣性思維排除。