一次性講清楚「連接池獲取連接慢」的所有原因
一、前言
應用連接數(shù)據(jù)庫基本上都是通過連接池去連接，比如常用的 HikariCP、Druid 等，在應用運行期間經常會出現(xiàn)獲取連接很慢的場景，大多數(shù)同學都是一頭霧水，不知道從哪下手。而且很多時候都是偶發(fā)場景，讓人頭疼不已，別著急，本文帶你逐步剖析獲取連接慢的所有可能的原因，以及對應的調優(yōu)手段，讓你成為連接池排障大師。
二、連接池監(jiān)控
排查問題的前提是發(fā)現(xiàn)問題，所以首先需要有連接池的詳細監(jiān)控，下面我們以 HikariCP 為例，簡單介紹幾個常用的指標的含義。
圖片
圖片
圖片
對應應用程序比較敏感的時間就是獲取連接耗時，因為它是同步的會直接影響鏈路的RT，下面我們就來逐步分析造成這個獲取連接耗時較高的所有可能性以及解決方案。
三、排查思路
連接池存在等待連接
獲取連接耗時較高最直接的原因就是存在等待連接數(shù)，這種情況直接觀測等待連接數(shù)的大盤即可
圖片
那么又有哪幾種情況會導致存在等待連接數(shù)呢？
- 連接池容量過小
如果日常的活躍連接數(shù)/總連接比例持續(xù)很高，或者 QPS * AVG-RT(s) > 連接總數(shù)說明當前連接池的最大連接數(shù)已經不足以支撐當前的流量，如何解決？
適當增加連接池最大連接數(shù)：連接數(shù)也不是越大越好，一般是根據(jù) CPU 核數(shù)決定，HikariCP 官方給出了一個公式可以做一下參考，最大連接數(shù)一般不要超過 50。
core_count 為core的數(shù)量 effective_spindle_count 為掛載的磁盤數(shù)量。core_count 為core的數(shù)量 effective_spindle_count 為掛載的磁盤數(shù)量。- 應用擴容：如果連接數(shù)調大后，仍然無法解決，說明單機的連接數(shù)已經達到上限，需要對應用進行擴容，但是需要注意擴容節(jié)點的數(shù)量，單機連接數(shù)*節(jié)點數(shù)量不要超過數(shù)據(jù)庫支持的最大連接數(shù)
有慢查詢&長事務
- 慢SQL
慢 SQL 相對來說比較好排查，數(shù)據(jù)庫或者數(shù)據(jù)庫中間件都有成熟的慢 SQL 采集工具。只需要分析一下指定時間段內是否有慢 SQL 即可。 如果SQL 優(yōu)化空間比較低，可以把慢 SQL 和核心業(yè)務分 2 個數(shù)據(jù)源，防止慢 SQL 影響正常核心業(yè)務。
- 長事務
長事務是很容易忽略的一種 case，可以通過觀測連接使用時間指標和 SQL 耗時來分析，如果連接使用平均耗時遠大于 SQL 平均耗時，那么說明有長事務。還可以根據(jù) HikariCP 自帶的連接泄露檢測來分析，當連接被借出后長時間未歸還（超過配置的閾值 leak-detection-threshold=30000）會打印借出時的堆棧，可以幫助我們快速定位。
圖片
還可以通過 RDS 的 SQL 洞察來分析是否有長事務，如果使用 Spring+JDBC 管理事務的情況下，開啟事務的命令是 SET autocommit=0，提交事務是 commit，這里根據(jù)數(shù)據(jù)庫線程 ID 來逐個分析，提交事務的時間-開啟事務的時間=事務持續(xù)時間。
應用負載過高
由于 HikariCP、Druid 在從連接池借出連接時，會有一個同步探活的操作，比如直接 MySQL 的 PING 命令或執(zhí)行 select 'X' 等，因為有網絡 IO，所以這里會讓當前線程進入阻塞狀態(tài)讓出 CPU 時間片。
圖片
在 CPU 繁忙時，執(zhí)行完網絡 IO 后等待獲取 CPU 時間片的時間較長，最終表現(xiàn)的結果就是獲取連接時間拉長。這種 case 的分析手段比較簡單，直接通過觀測應用的 CPU 和 Load 指標即可。
應用STW
在獲取連接方法開始到結束期間，如果應用發(fā)生了 STW，就會導致獲取連接耗時升高，需要結合 JVM 監(jiān)控 &GC 日志來分析，關于 GC 分析不是本文重點，這里簡單列舉幾個重點說明一下（以 ZGC 舉例）。
- JVM 監(jiān)控存在 Allocation Stall（垃圾回收阻塞，會暫停線程）或者暫停時間較長。
圖片
圖片
- GC 日志相對于監(jiān)控會更為準確一點，把日志文件直接丟到 https://gceasy.ycrash.cn/ 里面分析一下即可，會輸出詳細的報告，重點關注一下 STW 時間和分配阻塞。
圖片
圖片
網絡阻塞
這一類問題比較難以排查，具有偶發(fā)性和難以觀測的特點，網絡阻塞也分好幾種情況。
- 網絡抖動
這是最常見的一種情況，一般我們可以通過觀測應用所在主機的 TCP 重傳監(jiān)控是否有尖刺，但這里要注意下，TCP 重傳不代表一定是網絡抖動，也可能是網絡帶寬打滿或者數(shù)據(jù)庫 &DAL 異常。
圖片
除了監(jiān)控還可以通過網絡循環(huán)抓包來分析（主要磁盤容量不要保留太多文件），可以參考以下命令。
抓取 3306 端口的網絡包，存儲到 3306.pcap 文件中，-C 50 -W 10 代表一個文件最大 50M，最多保留 10 個 tcpdump -i eth0 port 3306 -w 3306.pcap -C 50 -W 10。
然后導入到 WireShark 工具中分析，重點關注 TCP Retransmission 即 TCP 重傳。
圖片
- 網絡阻塞
如機器帶寬打滿，具體表現(xiàn)也是 TCP 重傳，這里可以觀測機器的帶寬監(jiān)控和機器支持的最大帶寬做對比，看看是否超過限制。
圖片
數(shù)據(jù)庫&數(shù)據(jù)庫中間件異常
當數(shù)據(jù)庫或者數(shù)據(jù)庫中間件出現(xiàn)異常時，對于上游應用的表現(xiàn)大多數(shù)就是 SQL RT 增高、TCP 重傳。如果懷疑是數(shù)據(jù)庫或者數(shù)據(jù)庫中間件出現(xiàn)異常，可以先確定自己的應用連的是哪個庫，這里可以通過應用監(jiān)控（上下游 -RDS）直觀的看到應用連接的具體的庫信息，然后再觀測對應 RDS 和數(shù)據(jù)庫中間件的監(jiān)控進一步分析。
圖片
- 如果是數(shù)據(jù)庫中間件域名，就可以看數(shù)據(jù)庫中間件的監(jiān)控大盤。
圖片
如果數(shù)據(jù)庫中間件本身沒有異常，可以繼續(xù)下鉆到 RDS。
圖片
- 如果是 RM/RR 開頭的，說明連的是 RDS，可以看阿里云的 RDS 監(jiān)控，把下面的 Rdsid 替換一下即可。
https://rdsnext.console.aliyun.com/detail/{替換成rdsId}/performance?reginotallow=cn-hangzhou&DedicatedHostGroupId=重點觀測 CPU內存利用率 & IOPS 使用率，也可以框選指定時間段進行自動診斷。
圖片
四、總結
本文列舉了幾乎所有可能導致連接池獲取連接慢的 case，相信看完的讀者以后再遇到此類問題時，再也不會一頭霧水了。學會自助排查，不光可以提升自己的排障能力，同時也能減輕各位中間件 &DBA 小伙伴的客服壓力。
參考文檔：https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
