国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Mongodb日常性能問題處理案例分享

IT那活兒 / 3047人閱讀
Mongodb日常性能問題處理案例分享
[
問題描述
]


某日午間,業(yè)務側反饋mongodb數據庫異常,業(yè)務側報錯信息如下:

11:33:09Closed connection [connectionId{localValue:1182, serverValue:2880879}] to 10.**.**.**:27017 because there was a socket exception raised by this connection.

并且該問題從10:45開始影響業(yè)務,業(yè)務側異常情況突增:


[
問題分析處理
]


看到socketexception,立馬想到前段時間出現的因為網絡和連接風暴導致的連接延遲從而引起業(yè)務側重啟的問題,重啟過程中就出現大量的socket異常報錯。所以立即用shell腳本分析每秒連接和斷開連接情況,但是并未出現會話異常斷開。但從后臺日志上可看到如下信息:

2020-10-30T10:30:03.324+0800 I ACCESS   [conn2875701] Successfully authenticated as principal ringbacktone on admin from client 10.25.148.159:24045

2020-10-30T10:30:04.520+0800 I COMMAND  [conn2875694] command ri***one_prod.D**bt command: find { find: "D***rbt", filter: { dataStatus: { $in: [ "9", "10", "11", "12" ] }, activityId: "PAC_***ECYDSHD" }, sort: { _id: 1 }, skip: 10700, limit: 1

00, $db: "rin***rod" } planSummary: IXSCAN { activityId: 1 } keysExamined:1626656 docsExamined:1626656 fromMultiPlanner:1 cursorExhausted:1 numYields:16621 nreturned:100 reslen:310338 locks:{ Global: { acquireCount: { r: 33244 } }, Database: { acqu

ireCount: { r: 16622 } }, Collection: { acquireCount: { r: 16622 } } } protocol:op_query 8827ms

2020-10-30T10:30:04.520+0800 I NETWORK  [conn2875694] Error sending response to client: SocketException: Broken pipe. Ending connection from 10.25.148.210:12170 (connection id: 2875694)


從上面的日志上可以看到日志在刷慢查詢,并提示socket異常,分析慢查詢,可知其已經是索引掃描,但是是skip……limit分頁查詢。將語句拿到備庫執(zhí)行,毫秒級出結果。而慢查詢一般不會導致socket異常,在以往的運維工作中,十分鐘以上的查詢都未導致socket異常。


繼續(xù)檢查主機負載,發(fā)現主機CPU、內存耗盡,并出現少量內存換頁


此時檢查currentOp會話并發(fā)情況:


由上圖可以看出,日志中出現的慢查詢并發(fā)數高達912個。

至此,問題基本確認,大并發(fā)的分頁查詢導致數據庫性能急劇下降,導致主機CPU、內存耗盡。通知業(yè)務側檢查,該語句是某活動的接口查詢業(yè)務。業(yè)務側停止此部分業(yè)務后,機器性能恢復,CPU下降到10%以內,但是主機內存并未釋放。此時,數據庫占用內存情況如下:


數據庫使用虛擬內存56GB,物理內存近48GB,而我們的WT引擎的cache配置才20G,那么內存耗費在什么地方呢??繼續(xù)檢查db.serverStatus()輸出結果進行分析,發(fā)現tcmalloc分配器緩存了大量的內存。


消耗的內存找到了,但是我們沒法通過通過命令立即釋放緩存,而通過其他方案強制回收內存也可能導致嚴重的性能問題,此時我們發(fā)現業(yè)務停了后,機器未再出現換頁,所以不再對內存進行特別的處理,等mongodb逐漸釋放內存。


[
總結
]


無論在什么數據庫中,分頁問題均是越到后面越慢,當出現大并發(fā)分頁查詢的時候,可能導致數據庫性能急劇下降。在mongodb中,如果要使用到分頁,建議不要使用skip……limit的方式分析,而采用seekmethod,即每次分頁取出最后一條數據的某個值,然后再根據該值取limit的方式進行。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/130103.html

相關文章

  • Leaf in the Wild: Stratio整合Apache和MongoDB為世界上最大的銀行

    摘要:以及大數據平臺都已經進行了集成并且處于企業(yè)就緒狀態(tài)。因此,顧客避免浪費時間在安裝配置及監(jiān)控系統(tǒng)方面。注意防止數據頻繁移動。 本文源地址:http://www.mongoing.com/blog/post/leaf-in-the-wild-stratio-integrates-apache-spark-and-mongodb-to-unlock-new-customer-insights...

    BDEEFE 評論0 收藏0
  • 開源|性能優(yōu)化利器:數據庫審核平臺Themis的選型與實踐

    摘要:正是存在問題,促使我們考慮引入數據庫審核平臺。的確,與很多互聯網公司相比,數據庫數十套的估摸并不是太大但與互聯網類公司不同,類似宜信這類金融類公司對數據庫的依賴性更大,大量的應用是重數據庫類的,且其使用復雜程度也遠比互聯網類的復雜。 作者:韓鋒 出處:DBAplus社群分享 Themis開源地址:https://github.com/CreditEaseDBA 拓展閱讀:宜信開源|數...

    wenhai.he 評論0 收藏0
  • 數據庫收集 - 收藏集 - 掘金

    摘要:前言在使用加載數據數據庫常見的優(yōu)化操作后端掘金一索引將放第一位,不用說,這種優(yōu)化方式我們一直都在悄悄使用,那便是主鍵索引。 Redis 內存壓縮實戰(zhàn) - 后端 - 掘金在討論Redis內存壓縮的時候,我們需要了解一下幾個Redis的相關知識。 壓縮列表 ziplist Redis的ziplist是用一段連續(xù)的內存來存儲列表數據的一個數據結構,它的結構示例如下圖 zlbytes: 記錄整...

    Little_XM 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<