資訊專欄INFORMATION COLUMN
某日午間，業(yè)務(wù)側(cè)反饋mongodb數(shù)據(jù)庫異常，業(yè)務(wù)側(cè)報(bào)錯(cuò)信息如下：
| 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è)務(wù)，業(yè)務(wù)側(cè)異常情況突增：
看到socketexception，立馬想到前段時(shí)間出現(xiàn)的因?yàn)榫W(wǎng)絡(luò)和連接風(fēng)暴導(dǎo)致的連接延遲從而引起業(yè)務(wù)側(cè)重啟的問題，重啟過程中就出現(xiàn)大量的socket異常報(bào)錯(cuò)。所以立即用shell腳本分析每秒連接和斷開連接情況，但是并未出現(xiàn)會(huì)話異常斷開。但從后臺(tái)日志上可看到如下信息：
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異常，分析慢查詢，可知其已經(jīng)是索引掃描，但是是skip……limit分頁查詢。將語句拿到備庫執(zhí)行，毫秒級(jí)出結(jié)果。而慢查詢一般不會(huì)導(dǎo)致socket異常，在以往的運(yùn)維工作中，十分鐘以上的查詢都未導(dǎo)致socket異常。
繼續(xù)檢查主機(jī)負(fù)載，發(fā)現(xiàn)主機(jī)CPU、內(nèi)存耗盡，并出現(xiàn)少量內(nèi)存換頁
此時(shí)檢查currentOp會(huì)話并發(fā)情況：
由上圖可以看出，日志中出現(xiàn)的慢查詢并發(fā)數(shù)高達(dá)912個(gè)。
至此，問題基本確認(rèn)，大并發(fā)的分頁查詢導(dǎo)致數(shù)據(jù)庫性能急劇下降，導(dǎo)致主機(jī)CPU、內(nèi)存耗盡。通知業(yè)務(wù)側(cè)檢查，該語句是某活動(dòng)的接口查詢業(yè)務(wù)。業(yè)務(wù)側(cè)停止此部分業(yè)務(wù)后，機(jī)器性能恢復(fù)，CPU下降到10%以內(nèi)，但是主機(jī)內(nèi)存并未釋放。此時(shí)，數(shù)據(jù)庫占用內(nèi)存情況如下：
數(shù)據(jù)庫使用虛擬內(nèi)存56GB，物理內(nèi)存近48GB，而我們的WT引擎的cache配置才20G，那么內(nèi)存耗費(fèi)在什么地方呢？？繼續(xù)檢查db.serverStatus()輸出結(jié)果進(jìn)行分析，發(fā)現(xiàn)tcmalloc分配器緩存了大量的內(nèi)存。
消耗的內(nèi)存找到了，但是我們沒法通過通過命令立即釋放緩存，而通過其他方案強(qiáng)制回收內(nèi)存也可能導(dǎo)致嚴(yán)重的性能問題，此時(shí)我們發(fā)現(xiàn)業(yè)務(wù)停了后，機(jī)器未再出現(xiàn)換頁，所以不再對(duì)內(nèi)存進(jìn)行特別的處理，等mongodb逐漸釋放內(nèi)存。
無論在什么數(shù)據(jù)庫中，分頁問題均是越到后面越慢，當(dāng)出現(xiàn)大并發(fā)分頁查詢的時(shí)候，可能導(dǎo)致數(shù)據(jù)庫性能急劇下降。在mongodb中，如果要使用到分頁，建議不要使用skip……limit的方式分析，而采用seekmethod，即每次分頁取出最后一條數(shù)據(jù)的某個(gè)值，然后再根據(jù)該值取limit的方式進(jìn)行。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/130103.html
摘要：以及大數(shù)據(jù)平臺(tái)都已經(jīng)進(jìn)行了集成并且處于企業(yè)就緒狀態(tài)。因此，顧客避免浪費(fèi)時(shí)間在安裝配置及監(jiān)控系統(tǒng)方面。注意防止數(shù)據(jù)頻繁移動(dòng)。 本文源地址：http://www.mongoing.com/blog/post/leaf-in-the-wild-stratio-integrates-apache-spark-and-mongodb-to-unlock-new-customer-insights...
摘要：正是存在問題，促使我們考慮引入數(shù)據(jù)庫審核平臺(tái)。的確，與很多互聯(lián)網(wǎng)公司相比，數(shù)據(jù)庫數(shù)十套的估摸并不是太大但與互聯(lián)網(wǎng)類公司不同，類似宜信這類金融類公司對(duì)數(shù)據(jù)庫的依賴性更大，大量的應(yīng)用是重?cái)?shù)據(jù)庫類的，且其使用復(fù)雜程度也遠(yuǎn)比互聯(lián)網(wǎng)類的復(fù)雜。 作者：韓鋒 出處：DBAplus社群分享 Themis開源地址：https://github.com/CreditEaseDBA 拓展閱讀：宜信開源|數(shù)...
摘要：前言在使用加載數(shù)據(jù)數(shù)據(jù)庫常見的優(yōu)化操作后端掘金一索引將放第一位，不用說，這種優(yōu)化方式我們一直都在悄悄使用，那便是主鍵索引。 Redis 內(nèi)存壓縮實(shí)戰(zhàn) - 后端 - 掘金在討論Redis內(nèi)存壓縮的時(shí)候，我們需要了解一下幾個(gè)Redis的相關(guān)知識(shí)。 壓縮列表 ziplist Redis的ziplist是用一段連續(xù)的內(nèi)存來存儲(chǔ)列表數(shù)據(jù)的一個(gè)數(shù)據(jù)結(jié)構(gòu)，它的結(jié)構(gòu)示例如下圖 zlbytes: 記錄整...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
