最近在進行性能壓測, 想驗證一下產品的極限性能, 在使用openpower 2路22核(SMT4)176線程 512G內存的服務器上面進行性能壓測
壓測進行到1000並發或者是2000並發時性能有一定的衰減, 有開發確認, 數據庫事務僅是比較短促的OLTP的保存操作, 耗時都比較短 ,
所以在這種情況下, 將數據庫連接池的 大小 從2000逐步遞減到 350 左右, 性能壓測有了一定提高. 並發相應時間從7s 變成了3s 左右, 並且性能比較穩定了.
初步懷疑問題原因在於 較高連接數時 操作系統進行 線程調度時的損耗會比較大,如果設置超多的連接池數據, 並且要求數據庫服務器也提高max-connections 數目, 會導致
應用后端的 jvm 內的 connection pool 出現大量的 線程切換, 影響性能, 在數據庫端, 如果數據庫保持較多的關於客戶端的db connection 連接, 也需要進行數據庫服務器層面的線程切換.
並且前端時間出現過 jvm 的crash 現象, 懷疑也是在Openpower上面的 openjdk的 jvm 到達 三四千線程之后 容易出現穩定性問題,
在這里一直有一個不太明白的事項:
springboot 里面有兩個連接池 一個是為前端http服務的 tomcat http連接池, 這個連接池數量一樣可能會要求比較高一些.
雖然數據庫事務比較短促, 但是可能需要客戶端與應用服務器保持長連接, 應用服務器也需要較長時間的分析客戶請求, 訪問數據庫, 處理數據庫返回數據, 打包傳遞給客戶端等步驟, 這些步驟可能需要較長的時間來進行處理.
有時為了安全客戶端和應用服務器端還會保持一個keepalive 的通信機制, 定期校驗更換token 以保證安全.
剛才看了下 我這邊 登錄服務器 就產生了 7個tcp連接
可以明顯看到 是一個chrome 的進程在處理相關業務
然后在服務器端可以看到有多個連接
然后一段時間不報錯就會立馬降為 1個 連接 時間大約為1 min
所以懷疑用戶並發時可能會占用較多的http連接池.
看到這么一個數據
148 11840 okhttp3.internal.connection.RealConnection
懷疑跟這個數據有點靠近
感覺 http 連接池 比較輕量 也不會占用太多的資源
但是數據庫連接池比較 狠一些 數據庫需要做相關的 保持狀態以及事務處理 所以不能太多
但是發現數據庫連接池的大小可能大於實際的物理連接
[root@CentOS8 ~]# echo "當前數據庫連接池大小為:" $(jmap -histo `jps |grep caf |awk '{print $1}'` |grep PoolEntry$ |awk '{print $2}') 當前數據庫連接池大小為: 89 [root@CentOS8 ~]# lsof -i:5236 |grep 29490 |wc -l 23
這一塊理解的不太清楚
只是懷疑這個http 的連接數是 okhttp的 后面再給tomcat 進行處理.
但是tomcat的連接數多少可能需要通過http-nio 才分析.
比較忙 改天再整理