MongoDB最大連線數設定失效的異常分析過程與解決方法
背景介紹:
查詢MongoDB配置引數,可以知道關於最大連線數的引數是maxConns。但是連線例項後,檢視支援的最大連線數,還是預設的819。
說明:最大連線數是由maxConn (maxIncomingConnections)和作業系統單個程序能開啟的最大檔案描述符數總量的80%決定的,取兩個之間的最小值。預設單個程序能開啟的最大檔案描述符數為1024,1024*80% = 819.2 取整數819。所以最大可以支援的併發連線數為819。
案例重現
以下為本次測試MongoDB案例配置的引數。
啟動後檢視最大連線數。
執行命令:db.serverStatus().connections
Current表示當前到例項上正在執行的連線數。
Available表示當前例項還可以支援的併發連線數。
也就是說此例項最大能支援的併發連線數為:Current+available=3+816=819.
所以設定的maxConns引數無效。所以設定的maxConns引數無效!所以設定的maxConns引數無效!所以設定的maxConns引數無效!
答案求索
此時檢視檢視網上相關資料,大部分集中在 Linux系統最大檔案描述符數。檢視我們系統配置,此時已經是65535了。不是系統最大檔案描述符數限制的了。
轉個彎,因為我們是為作業系統是 centos 7 ,所以我們的mongodb服務是透過systemctl來管理的。那如果是通過service 命令來管理此服務呢?
測試1 測試用service來管理mongodb 服務 對最大連線數的影響
(1) 在/etc/init.d目錄下建立名為mongodbtest0903的服務;
(2) 服務的配置如下:
(3) 賦予執行許可權,然後開啟服務
(4) 此時檢視連線數為2500(為maxConns引數值)
(5) 關閉 mongodb 服務
以上說明用service 來管理服務,最大連線數引數起作用了。
測試2 如果直接用Mongodb command開啟呢?
(1) 直接開啟
(2)此時檢視連線數為2500(為maxConns引數值)
(3)關閉此服務
以上說明直接開啟Mongodb服務,最大連線數引數起作用了。
通過service和 mongodb命令啟動服務,最大連線數都是設定的引數,而通過systemctl來開啟此服務就變成了預設的819.
探究
我們來具體分析下systemctl 開啟的 mongodb 服務(此服務定義為mongodbtest0903)。
(1)檢視此服務的所有配置細節的命令
systemctl show mongodbtest0903.service
部分細節如下
此時 LimitNOFILE=4096
(2) 檢視此服務的程序,以及此程序下的資源限制
程序的資源限制
終於看到了 資源限制是1024。
問題1:為什麼經過systemctl 啟動的mongodb服務變成了預設的819.
回答:因為systemctl 啟動的服務程序其最大檔案描述符數變成了1024. 1024*80% = 819.2 取整數819.
問題2:為什麼系統設定的最大是65525 而 systemctl 變成了1024.
在Centos7系統中,使用Systemd替代了之前的SysV。/etc/security/limits.conf檔案的配置作用域縮小了。/etc/security/limits.conf的配置,只適用於通過PAM認證登入使用者的資源限制,它對systemd的service的資源限制不生效。
其實仔細檢視/etc/security/limits.conf檔案的註釋,說明了對系統服務不生效。
解決方案
解決方案,知道了問題所在,針對此問題尋找解決方案相對容易了。
解決方案1:針對單個 systemctl 管理的服務。
在/lib/systemd/system中找到具體的服務,增加
# (open files) LimitNOFILE=64000
命令。 修改後為:
重啟服務,此時連線檢視最大連線數為2500,到達設定的引數。
解決方案2 網上有種方案是對systemd全域性修改。此方案本作者沒有驗證,轉述如下,意思是修改/etc/systemd/system.conf 即可:
全域性的配置,放在檔案/etc/systemd/system.conf和/etc/systemd/user.conf。 同時,也會載入兩個對應的目錄中的所有.conf檔案/etc/systemd/system.conf.d/*.conf和/etc/systemd/user.conf.d/*.conf
其中,system.conf是系統例項使用的,user.conf使用者例項使用的。一般的sevice,使用system.conf中的配置即可。systemd.conf.d/*.conf中配置會覆蓋system.conf。
DefaultLimitCORE=infinity
DefaultLimitNOFILE=100000
DefaultLimitNPROC=100000
注意:修改了system.conf後,需要重啟系統才會生效。
因為伺服器上systemctl會管理多種服務,為減少對其它服務的影響,建議在單個服務上修改,集採用第一種方案。
其他相關知識
(1)mysql 服務也會遇到類似問題;
(2)* nofiles - soft limit on the number of file descriptors a process may have;
(3)*soft limit與hard limit的不同:soft limit是真正生效的限制值,而hard limit僅僅是soft limit調整範圍的一個上限。
連線數優化:
通過serverStatus查詢連線數:
mongo> db.serverStatus().connections
每個連線都是一個執行緒,需要一個Stack,Linux下預設的Stack設定一般比較大:
shell> ulimit -a | grep stack stack size (kbytes,-s) 10240
至於MongoDB實際使用的Stack大小,可以用如下命令確認(單位:K):
shell> cat /proc/$(pidof mongod)/limits | grep stack | awk -F 'size' '{print int($NF)/1024}'
如果Stack過大(比如:10240K)的話沒有意義,簡單對照命令結果中的Size和Rss:
shell> cat /proc/$(pidof mongod)/smaps | grep 10240 -A 10
所有連線消耗的記憶體加起來會相當驚人,推薦把Stack設定小一點,比如說1024:
shell> ulimit -s 1024
注:從MongoDB1.8.3開始,MongoDB會在啟動時自動設定Stack。
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對我們的支援。