參考在前, 尊重知識產權
- 幾個監控工具
- 優化的幾點原則
其實并不是單單的mongo性能優化, 這里記錄了整個問題的分析過程.
問題背景:?
Mongo是開始接觸數據處理的一個窗口, 為什么用mongo? 省事, 穩定, 能力強就直接上了, 所以我們從一開始收集數據的基調就定了, 規范數據上報結構, 通過統一的server接口收集業務信息, 雖然mongo是NoSQL, 不過設計上一樣對結構比較考究, 主要是為了后續使用分析方便, 添加版本管理. 并且基于mongo, django, matplot設計了第一個項目, 使用mongo的mapreduce功能, 和django的簡易部署使用, 用matplot做可視化. 可以做到只編輯map&reduce&finally腳本, 簡單加工過濾后, 由django直接顯示, 并且可以很方便的和報表系統對接. 這個系統支撐了一年多的業務分析需求, 并且現在還在發揮作用.
之前總結的太少, 一開頭就想多說, brake. 真正的背景, 之前一直是用的2.6, 性能和分析使用都沒有大問題, 因為只收集有分析價值的規范化數據加上合理的元信息管理, 所以這塊的數據增長可控. 不過一個多月前, 由于服務器監控的bug, 導致磁盤寫滿, 服務宕機, 并且部分數據損壞, 所以索性升級到了3.4, 主要考慮3.4的性能有大的提升, 并且從全局鎖變成了表級別的鎖?
如圖, 是3.0和2.6的一個比較, 其實3.2開始, mongo做了非常大的調整, 以至于不兼容老版本的數據, 無法平滑的遷移. 對我們來說, 大部分有價值的分析已經作為中間分析結果存儲在mysql或者es里, 所以可以暫時考慮不遷移老數據, 所以這次事故是一個很好的契機.
ps: 下圖里多線程寫對性能的提升還是比較有限的, 親測
我們這塊的數據流結構是這樣的, 這塊兩年沒改動了.
? ? ? ? ? ? ? ? ? ? ? ? ? ? $Cloud --> AMQ --> Consumer --> MongoDB
問題發生在周一, 由ES提供的數據檢索服務發現分布式MCU的監控數據嚴重缺失, 部分不需要實時處理的數據同步延遲也很大,?
如圖, 這是分布式MCU的健康數據, 理論上數量不會在時間軸上有太大的變動.
問題的分析:
首先, 判斷是基于mongo的ETL清洗邏輯出了問題, 導致丟失或者更新不及時. 所以去任務調度部分查看日志, 發現每次的采樣計算耗時在5 ~ 10分鐘, 這個任務設計上需要保證在1分鐘內完成, 否則數據堆積, 不能正確采樣數據, 延遲數據直接丟棄. 計算的時間主要消耗在mongo側, 所以首先查看mongo的數據寫入審計監控.
有部分異動數據, 不過不應該會影響性能, 沒有大規模的新數據產生.
于是, 需要查看mongo在干什么, 這里有三個分析性能的重要工具或者方法, 開頭參考鏈接里應該有
一是, 通過設計profile查看慢請求, 比如把運算超過100ms以上的都記錄下來
二是, mongostat, 是了解mongod整體工作情況的重要工具, 應該不定期的去看看, 了解下運行狀態, 3.4的輸出做了一些調整, 看官方文檔最好, -->?mongostat
三是, mongotop, 會以collections為單位, 記錄耗時操作時間, 排序, 默認一秒鐘一次. -->?mongotop
進一步的分析, 上面幾個工具都用了, 抱歉沒有保留截圖, 最終發現耗時操作只在dmcu的計算上, 所以還需要重看一下計算代碼, 雖然之前穩定運行過一年多.?
直接說問題吧, 注意到上圖的查詢條件, 看到這條log的時候, 就突然想到, 時間戳沒有索引, 事實證明確實沒有索引. 那么為什么之前工作沒有問題, 想必是剛切到3.4后沒有什么數據, 只顧欣喜升級成功吧. 談到索引, 多說一點應該注意的, 關于時間的所以最好建立倒排索引, 因為畢竟我們的分析通常來說, 在時間軸上, 越近的越有價值, 倒排理論上可以提高業務分析效率.
到此, 可以判定這是一個低級的失誤, 不過我們業務上遇到的很多重大問題又有幾個不是回過頭來看 "低級" 的呢? 添加索引之后, 時間從10分鐘降到10秒鐘.?
不過問題并沒有結束, 數據的延遲依然很嚴重.
現象, 類似上圖, 有堆積的命令, 但是沒有實際插入數據, 貌似大量的插入請求被堆積了起來, 等著什么, 或者等風來. 過一段時間后, 就會爆發性的插入大量的數據, 這樣的數據流失完全不能被后端業務使用的, 貌似也是個讓人崩潰的問題, 因為之前用低版本根本沒遇到過.?
那現在只能看插入數據, 也就是consumer的代碼, 發現之前用的insert接口被摒棄了, 已經不建議使用.
并且, acknowledge write被默認設置成了true. 因為寫入性能定會很差, 而且根據之前描述的現象貌似用這個接口mongo側會有bug.?
所以這里需要改寫. 改寫之前測試了一下性能, 發現200條數據, 四個進程, 平均要用10 ~ 15秒, 這個性能遠小于之前的測試性能.?
這塊代碼的重構重要涉及了兩個方面, 一個是多線程的使用, 另一個是批量插入接口的使用, 并且需要兼顧數據延遲的控制, 目前的策略是小于10秒. 重構之后, 相同的測試條件提升了30 ~ 50倍. 這塊數據的處理又順暢了.
Tips:?
Insert_many, 有個參數是ordered, 對于統計分析類的數據, 順序并不重要, 而且我們定義的數據是自帶時間戳的, 如果ordered=true的話, 每個collection的數據插入需要等待上一條完成. 每次插入的數據量, 一般不大于1000, 因為內部實現分批插入, 比如傳入2000條, 會分兩批插入.
總結:
就這件事來說主要是兩個優化最有意義, 索引和多進程批量插入的使用.
其它的優化, 其實還有很多, 系統上的讀寫分離, 存儲引擎的選擇等, 硬件上的IO優化, 內存優化等
Mongo在所設計的系統里, 是一個類似hdfs的角色, 用于存儲結構化日志, 提供離線分析和查詢, 雖然以后會考慮引入其他的存儲框架, 來容納更大規模的, 更靈活的日志數據, 但是目前看都可以和mongo有效的結合, 相得益彰, 所以會一直維護和挖掘他的潛力. 稍后會分享一下如何和其它組件配合使用.
歡迎大家一起討論.
