一個cp命令引起的mongodb大量慢查詢

遇到問題：凌晨收到報警，某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查詢性能直線降低。

因而咱們聯繫了某雲，一個普通雲盤的性能怎會如此低！

以上查問題的思路，最開始也沒有很順利。起初文件較小並無猜想到是日誌拷貝。查問題的時候不能以慣性思惟排除。