一個(gè)cp命令引發(fā)的mongodb大量慢查詢

遇到問題：凌晨收到報(bào)警，某MongoDB服務(wù)器cpu load超過8。由于沒有影響到業(yè)務(wù)，第二天一早開始查原因。

創(chuàng)新互聯(lián)主要從事做網(wǎng)站、網(wǎng)站設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)代縣,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):13518219792

查原因：

1. 先了解該服務(wù)器上的應(yīng)用有哪些

    該db服務(wù)器主要應(yīng)用只有mongodb。于是開始查詢mongodb日志：

通過凌晨的日志mongodb.log查看，有大量的慢查詢，但實(shí)際上這些表都非常小，只有幾百行數(shù)據(jù)，而且表還有索引，卻僅僅一個(gè)查詢花了60~80s，慢查詢之后的日志顯示該節(jié)點(diǎn)不被其他節(jié)點(diǎn)檢測(cè)到（mongodb復(fù)制集形式）。

由于一個(gè)小表的查詢都需要判斷70s左右，而且mongodb部署的是復(fù)制集形式（其他的查詢節(jié)點(diǎn)都是正常的）可以判斷，可能是這臺(tái)db的性能方面影響了mongodb，而非mongodb本身的性能影響。

2. 于是查看凌晨有什么任務(wù)再跑。

crontab -l 發(fā)現(xiàn)確實(shí)凌晨有一個(gè)任務(wù)。是一個(gè)切割日志的腳本。大概就是把日志cp到另一個(gè)目錄，然后將當(dāng)前日志清空，繼續(xù)記錄新的一天的日志。

但這個(gè)日志平時(shí)都較小，也運(yùn)行了很長(zhǎng)時(shí)間.只能試一試的看看日志目錄

看到日志突然就這么大了。難道是因?yàn)橥砩蟘p 文件的時(shí)候?qū)е铝耍?/p>

差不多判斷問題出現(xiàn)在 cp導(dǎo)致了io負(fù)載過高，進(jìn)而導(dǎo)致了cpu load 過高。

3. 復(fù)現(xiàn)問題

由于該操作在夜間操作，未影響線上業(yè)務(wù)。故手動(dòng)操作cp，復(fù)現(xiàn)問題。

cp 了一個(gè)近3g的文件， 如下圖：看到產(chǎn)生的I/O請(qǐng)求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤可能存在瓶頸。

跟著cpu load也 上升到10 （每一分鐘的cpu load 值）左右。

解決問題：

將較大的日志從mongodb服務(wù)器分離出。

將小日子日志腳本切割改為系統(tǒng)logrotate切割。logrotate會(huì)在系統(tǒng)空閑的狀態(tài)進(jìn)行操作。

可是為什么拷貝了一個(gè)3g的文件，就會(huì)導(dǎo)致cpu load 高達(dá)10. 進(jìn)而導(dǎo)致mongodb查詢性能直線下降。

于是我們聯(lián)系了某云，一個(gè)普通云盤的性能怎會(huì)如此低！

以上查問題的思路，最開始也沒有很順利。起初文件較小并沒有猜測(cè)到是日志拷貝。查問題的時(shí)候不能以慣性思維排除。

網(wǎng)頁(yè)名稱：一個(gè)cp命令引發(fā)的mongodb大量慢查詢
當(dāng)前網(wǎng)址：http://m.jiaotiyi.com/article/geggdj.html