遇到問題：凌晨收到報警，某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查詢效能直線下降。
於是我們聯絡了某雲，乙個普通雲盤的效能怎會如此低！
以上查問題的思路，最開始也沒有很順利。起初檔案較小並沒有猜測到是日誌拷貝。查問題的時候不能以慣性思維排除。
每天乙個linux命令 cp 命令
cp命令用來複製檔案或者目錄，是linux系統中最常用的命令之一。一般情況下，shell會設定乙個別名，在命令列下複製檔案時，如果目標檔案已經存在，就會詢問是否覆蓋，不管你是否使用 i引數。但是如果是在shell指令碼中執行cp時，沒有 i引數時不會詢問是否覆蓋。這說明命令列和shell指令碼的執行...
每天乙個 Linux 命令 cp 命令
cp命令用來複製檔案或者目錄，是linux系統中最常用的命令之一。一般情況下，shell會設定乙個別名，在命令列下複製檔案時，如果目標檔案已經存在，就會詢問是否覆蓋，不管你是否使用 i引數。但是如果是在shell指令碼中執行cp時，沒有 i引數時不會詢問是否覆蓋。這說明命令列和shell指令碼的執行...
每天乙個liunx 命令 cp
cp 命令 作用cp 複製命令，用於系統間檔案或者目錄的複製 用法usage cp option t source dest 引數說明 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 a 或 archive 此引數的...