小米平板5 Pro 12.4簡評：多專多能 兼顧影音娛樂的大屏利器
疫情帶來了網課，網課盤活了安卓平板，安卓平板市場雖然中途停滯了幾年，但好的一點就是停滯的這幾年行業又有了新的發展方向，例如超窄邊框、高刷新率、多攝鏡頭組合等，這就讓安卓
應用連接數據庫基本上都是通過連接池去連接，比如常用的 HikariCP、Druid 等，在應用運行期間經常會出現獲取連接很慢的場景，大多數同學都是一頭霧水，不知道從哪下手。而且很多時候都是偶發場景，讓人頭疼不已，別著急，本文帶你逐步剖析獲取連接慢的所有可能的原因，以及對應的調優手段，讓你成為連接池排障大師。
排查問題的前提是發現問題，所以首先需要有連接池的詳細監控，下面我們以 HikariCP 為例，簡單介紹幾個常用的指標的含義。
圖片
圖片
圖片
對應應用程序比較敏感的時間就是獲取連接耗時，因為它是同步的會直接影響鏈路的RT，下面我們就來逐步分析造成這個獲取連接耗時較高的所有可能性以及解決方案。
獲取連接耗時較高最直接的原因就是存在等待連接數，這種情況直接觀測等待連接數的大盤即可
圖片
那么又有哪幾種情況會導致存在等待連接數呢？
如果日常的活躍連接數/總連接比例持續很高，或者 QPS * AVG-RT(s) > 連接總數說明當前連接池的最大連接數已經不足以支撐當前的流量，如何解決？
適當增加連接池最大連接數：連接數也不是越大越好，一般是根據 CPU 核數決定，HikariCP 官方給出了一個公式可以做一下參考，最大連接數一般不要超過 50。
core_count 為core的數量 effective_spindle_count 為掛載的磁盤數量。core_count 為core的數量 effective_spindle_count 為掛載的磁盤數量。慢 SQL 相對來說比較好排查，數據庫或者數據庫中間件都有成熟的慢 SQL 采集工具。只需要分析一下指定時間段內是否有慢 SQL 即可。 如果SQL 優化空間比較低，可以把慢 SQL 和核心業務分 2 個數據源，防止慢 SQL 影響正常核心業務。
長事務是很容易忽略的一種 case，可以通過觀測連接使用時間指標和 SQL 耗時來分析，如果連接使用平均耗時遠大于 SQL 平均耗時，那么說明有長事務。還可以根據 HikariCP 自帶的連接泄露檢測來分析，當連接被借出后長時間未歸還（超過配置的閾值 leak-detection-threshold=30000）會打印借出時的堆棧，可以幫助我們快速定位。
圖片
還可以通過 RDS 的 SQL 洞察來分析是否有長事務，如果使用 Spring+JDBC 管理事務的情況下，開啟事務的命令是 SET autocommit=0，提交事務是 commit，這里根據數據庫線程 ID 來逐個分析，提交事務的時間-開啟事務的時間=事務持續時間。
應用負載過高
由于 HikariCP、Druid 在從連接池借出連接時，會有一個同步探活的操作，比如直接 MySQL 的 PING 命令或執行 select 'X' 等，因為有網絡 IO，所以這里會讓當前線程進入阻塞狀態讓出 CPU 時間片。
圖片
在 CPU 繁忙時，執行完網絡 IO 后等待獲取 CPU 時間片的時間較長，最終表現的結果就是獲取連接時間拉長。這種 case 的分析手段比較簡單，直接通過觀測應用的 CPU 和 Load 指標即可。
在獲取連接方法開始到結束期間，如果應用發生了 STW，就會導致獲取連接耗時升高，需要結合 JVM 監控 &GC 日志來分析，關于 GC 分析不是本文重點，這里簡單列舉幾個重點說明一下（以 ZGC 舉例）。
圖片
圖片
圖片
圖片
這一類問題比較難以排查，具有偶發性和難以觀測的特點，網絡阻塞也分好幾種情況。
這是最常見的一種情況，一般我們可以通過觀測應用所在主機的 TCP 重傳監控是否有尖刺，但這里要注意下，TCP 重傳不代表一定是網絡抖動，也可能是網絡帶寬打滿或者數據庫 &DAL 異常。
圖片
除了監控還可以通過網絡循環抓包來分析（主要磁盤容量不要保留太多文件），可以參考以下命令。
抓取 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 重傳。
圖片
如機器帶寬打滿，具體表現也是 TCP 重傳，這里可以觀測機器的帶寬監控和機器支持的最大帶寬做對比，看看是否超過限制。
圖片
當數據庫或者數據庫中間件出現異常時，對于上游應用的表現大多數就是 SQL RT 增高、TCP 重傳。如果懷疑是數據庫或者數據庫中間件出現異常，可以先確定自己的應用連的是哪個庫，這里可以通過應用監控（上下游 -RDS）直觀的看到應用連接的具體的庫信息，然后再觀測對應 RDS 和數據庫中間件的監控進一步分析。
圖片
圖片
如果數據庫中間件本身沒有異常，可以繼續下鉆到 RDS。
圖片
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
本文鏈接：http://www.www897cc.com/showinfo-26-38133-0.html一次性講清楚「連接池獲取連接慢」的所有原因｜
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： C 語言變長參數及其陷阱
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號