Mycat占用mysql連接數過多
阿新 • • 發佈:2018-03-06
mycat mysql 連接數過多 timeout 背景:mariadb,mycat中間件。
問題:DB連接數過多;開發使用程序使用連接池連mycat;
DB待優化項: interactive_timeout,wait_timeout 都是8小時默認值。
mycat配置:100個分片庫,和其他業務庫。現在分片庫用到16分片,後面尚未使用。
當前DB最大連接數:3000
mycat 版本:當前線上的mycat版本是1.5.8版本,推薦以後線上使用最穩定的 mycat1.6.5版本。 正常手段無法使用的時候,那麽就要找到DB為啥連接數過多。
"後連接仍舊重新連接。
這種情況很尷尬,找不到原因。
3. 審計日誌
再結合審計日誌,查看連接從哪來的,還是mycat 發過來的<heartbeat>select 1 </heartbeat>,暫時就可以定位mycat的heartbeat 問題,結合網上查找的heartbeat算法,
其中有一條是關於未用的DB連接算法:如果當前DB一直有訪問,那麽鏈接該DB 的heartbeat暫不執行,未用的DB鏈接300秒重新連接該DB。
問題:DB連接數過多;開發使用程序使用連接池連mycat;
DB待優化項: interactive_timeout,wait_timeout 都是8小時默認值。
mycat配置:100個分片庫,和其他業務庫。現在分片庫用到16分片,後面尚未使用。
當前DB最大連接數:3000
mycat 版本:當前線上的mycat版本是1.5.8版本,推薦以後線上使用最穩定的 mycat1.6.5版本。
經DB和開發碰面了解 這兩個timeout時間不能縮短,所以常規的優化手段不能使用:
正常DB連接數1000,數據庫兩個timeout為300--500,參數可以全局動態生效。
公司線上DB前段時間建總出現連接數過多問題,正常來說連接數1000,已經能夠滿足大部分需求。
1. 審計日誌
DB上部署過審計日誌,審計日誌部署請移步:審計日誌部署,審計日誌中可以查看到做壞事的壞小子是誰!
因為時間關系,未保存。但是從審計日誌中發現大量訪問連接sql就是‘select 1‘ ,也是mycat連接mysql的連接。
且該鏈接連的是大量尚未使用的物理庫。
至此審計日誌只能判斷到這裏。
2. DB層面
mariadb物理庫 information_schema 中processlist表記錄連接相關信息,比如 DB,HOST,INFO,STATUS等。而且能統計具體某個庫的連接數。
查詢後,發現很多沒有使用的DB中連接很多沒有釋放,大概占總連接數的60%左右,使用腳本 "kill id;
這種情況很尷尬,找不到原因。
3. 審計日誌
再結合審計日誌,查看連接從哪來的,還是mycat 發過來的<heartbeat>select 1 </heartbeat>,暫時就可以定位mycat的heartbeat 問題,結合網上查找的heartbeat算法,
其中有一條是關於未用的DB連接算法:如果當前DB一直有訪問,那麽鏈接該DB 的heartbeat暫不執行,未用的DB鏈接300秒重新連接該DB。
這算法是個人的理解,因能力有限,代碼閱讀能力低,只能理解個大概;現也能判斷個大概方向。
4.更改mycat配置
- 當前mycat配置:<schema><table datanode ></table></schema>datanode
需要減少未使用的datanode,減少後發現,連接數並未減少。
kill id; 後還是連接數會重新增長。判斷單單更改datanode不是解決問題的辦法。
- 更改<datanode></datanode>:
刪除尚未使用的<datanode></datanode>,再次kill id; 操作。未用的<datanode></datanode>連接不再出現。
至此問題解決,實驗文字敘述較多,描述較少,僅供讀者參考。
Mycat占用mysql連接數過多