這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)業(yè)務(wù)卡單與MongoDB性能記錄與分析是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：國(guó)際域名空間、虛擬空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、博湖網(wǎng)站維護(hù)、網(wǎng)站推廣。

事情的經(jīng)過(guò)是運(yùn)維，開(kāi)發(fā)均告訴我業(yè)務(wù)出現(xiàn)卡單，并且均懷疑是傳統(tǒng)數(shù)據(jù)庫(kù)的問(wèn)題，后面又覺(jué)得是MQ的問(wèn)題，最后在中午的時(shí)候發(fā)現(xiàn)MONGODB 由于上線不嚴(yán)格（主要是MONGODB DDL 的操作和普通數(shù)據(jù)庫(kù)不一樣，開(kāi)發(fā)的同學(xué)的自由度很大），所以造成數(shù)據(jù)都寫了不短的時(shí)間了，但相關(guān)的維護(hù)工作都沒(méi)有被告知相關(guān)部門。

一般來(lái)說(shuō)對(duì)于傳統(tǒng)數(shù)據(jù)庫(kù)的問(wèn)題發(fā)現(xiàn)其實(shí)從操作手段和方法上大致相同，而MONGO DB 作為NO SQL 數(shù)據(jù)庫(kù)，如何發(fā)現(xiàn)問(wèn)題，又怎么處理有的時(shí)候倒不是很清楚。

問(wèn)題1， 怎么查看慢查詢

一般來(lái)說(shuō)在MONGODB 的維護(hù)中有這樣一個(gè)問(wèn)題，就是盡量避免性能的影響將system.profile關(guān)閉，出了問(wèn)題然后在去打開(kāi)，然后在處理。起先我也是這樣去做的，但后期我發(fā)現(xiàn)這樣處理問(wèn)題不OK。先說(shuō)說(shuō)為什么要這樣做，在說(shuō)說(shuō)為什么后面有要打開(kāi)。

不打開(kāi)system.profile的原因

1 在系統(tǒng)遇到大量慢語(yǔ)句后會(huì)大量的插入慢查詢的記錄到這個(gè)系統(tǒng)表

2 這樣操作會(huì)造成可能的系統(tǒng)性能二次傷害

思路到底正確不正確，我是這樣想的，如果有針對(duì)MONGODB 慢查詢的監(jiān)控或者統(tǒng)計(jì)數(shù)字，并且可以進(jìn)行一個(gè)報(bào)警，那其實(shí)system.profile是應(yīng)該打開(kāi)的，哪怕會(huì)在出現(xiàn)大量慢查詢的時(shí)候出現(xiàn)一些性能的損失，但第一時(shí)間發(fā)現(xiàn)問(wèn)題是重要的，與其事后發(fā)現(xiàn)，不如一直準(zhǔn)備事前發(fā)現(xiàn)，出了問(wèn)題解決問(wèn)題就好，哪怕到時(shí)候在關(guān)掉呢。

這里有2個(gè)方法

1  實(shí)時(shí)監(jiān)控，可以寫一個(gè)腳本定時(shí)去運(yùn)行，1秒一次查詢 

db.currentOp({“secs_running”: {$gte: 3}})

這樣查詢的好處是，所有系統(tǒng)中不同的數(shù)據(jù)庫(kù)的慢語(yǔ)句都會(huì)被揪出來(lái)，然后直接寫到一個(gè)日志，或者在寫入到mongodb的表里面，然后可以去查詢或者進(jìn)行二次展示。

2 mongodb  profiler

 這個(gè)好處是簡(jiǎn)單，但如果你MONGODB 上的數(shù)據(jù)庫(kù)多，那每個(gè)數(shù)據(jù)庫(kù)都要設(shè)置打開(kāi)，并且可能相比較第一種方法，靈活度差。好處是收集的信息更豐富，針對(duì)性更強(qiáng)。

具體看那個(gè)就看你要什么了，當(dāng)然也可以兩個(gè)都用。

例如你要是想找到 system.profile 中 查詢慢的，并且超過(guò)1秒的查詢，以最近的出現(xiàn)問(wèn)題的語(yǔ)句從頭到尾的顯示?？梢杂孟旅娴恼Z(yǔ)句

db.system.profile.find( { op: { $eq : 'query' } } , 

{"millis": 1000}).sort( { ts : -1 } ).pretty()

當(dāng)然這樣做是否就OK 了，其實(shí)還差點(diǎn)，如果developer 問(wèn)你，HI 有慢查詢這段時(shí)間，MONGODB 的機(jī)器表現(xiàn)如何，是性能引起的問(wèn)題嗎，諸如此類的問(wèn)題，估計(jì)又得費(fèi)點(diǎn)心理，關(guān)鍵的是，誰(shuí)知道那陣子的機(jī)器的性能如何。

其實(shí)對(duì)比其他的數(shù)據(jù)庫(kù)，例如AWR 報(bào)告，或者 DWV 視圖系統(tǒng)，或者 sys 庫(kù)和 preformance_schema中的一些歷史表，或者從豐富的日志中，獲得所有想要的歷史和性能記錄在通過(guò)pgBadger 輸出成漂亮的分析報(bào)告。

那MONGODB 可以通過(guò)簡(jiǎn)單的mongostat 來(lái)將你要的東西來(lái)進(jìn)行一個(gè)記錄，寫一個(gè)腳本，定期的進(jìn)行日志的切換和廢棄，例如記錄一個(gè)禮拜的性能記錄，當(dāng)然間隔可以調(diào)整的大一些，然后對(duì)比慢查詢，你可以輕松的告訴開(kāi)發(fā)或者其他人員，那時(shí)那刻的MONGODB 到底在經(jīng)歷了什么，臟頁(yè)，當(dāng)時(shí)數(shù)據(jù)插入，以及CPU的使用率等等。當(dāng)然如果你安裝了 ops manager 則管理和性能監(jiān)控會(huì)更加的方便和可視化。

當(dāng)然這還沒(méi)有完，你也可以使用一些MySQL 中已經(jīng)熟知的工具集合中包含的MONGODB的工具來(lái)處理例如慢查詢，或者做一個(gè)簡(jiǎn)單的MONGODB 的 AWR。

上述就是小編為大家分享的業(yè)務(wù)卡單與MongoDB性能記錄與分析是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。