问题排查 —— OLAP平台获取查询引擎连接严重耗时
目錄
- 一、問題說明
- 二、原因查明
- 1. 數據庫連接池
- 2. Impala連接參數
- 3. 應用近期改動
- 4. 集群中連接建立數量
- 三、問題復現
- 四、問題解決
- 五、附錄
- 1.資料
- 2.C3P0相關參數
- 3.Impala機器相關參數
一、問題說明
BI平臺出現了查詢時快時慢的問題,查看監控發現獲取連接部分耗時飆升,相關監控如下:
正常情況下獲取連接耗時P99都在100ms以內,但是從某天開始,其耗時飆升到峰值時需要262k毫秒,嚴重拖慢了查詢耗時。
二、原因查明
1. 數據庫連接池
系統中使用的C3P0連接池,連接參數部分只設置了jdbcUrl、username、password、maxPoolSize和minPoolSize。 其中,maxPoolSize為20,minPoolSize為1。
2. Impala連接參數
Impala中fe_service_threads可以用來設置單個coordinater最大連接數,未對該參數作改動,默認為64,其具體含義為:
-
fe_service_threads值分別對Beeswax pool(impala shell等)、Hive Server2pool(jdbc\hue等)生效,即當配置值為64時,表示該節點最大可支持128個客戶端連接,其中Beeswax pool 64個,hiveserver2 pool 64個;fe_service_threads配置是對節點(coordinater)而言地,如當集群存在2個coordinater節點,并且fe_service_threads的配置為64時,集群最大可提供256個客戶端連接;
-
fe_service_threads限制包括空閑連接在內的所有客戶端連接,并不是單位時間的查詢并發數。
-
同一時間connection和session的對應關系是一一對應地,當手動關閉session時,連接會在下一次查詢提交時重建session,不會引起錯。
-
session關閉可能connection未關閉,session存在connection一定存在。
3. 應用近期改動
由于公司最近推進容器化部署,第一階段需進行混合部署,即發布一定數量的容器化服務并且不下線已有虛擬機服務,因此提供服務的機器數量從4臺變為了8臺。
4. 集群中連接建立數量
使用如下命令查看各IP在 Impala 查詢服務端口 21050(對于mysql則為3306)上建立連接數量情況。
sudo netstat -nat | grep 21050 | grep ESTABLISHED | awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn總共8臺線上機器連接Impala集群,集群中有四臺Coordinater,查看發現每臺Coordinater 21050端口連接數量都在80及以上,這已經超出了Impala最大連接數量了。
結合以上原因,推測是增加服務機器后引起,將提供服務的機器數量從8臺降低為4臺之后,線上服務獲取OLAP查詢引擎連接耗時回歸正常區間。
三、問題復現
開啟初始線程數64、最大線程數64、最小線程數64的服務,連接四臺Coordinater,這樣在發起查詢時會產生大量的Connection,使得端口連接建立數超過Impala集群單Coordinater最大允許連接數。
服務啟動后,查看監控發現getConnection耗時確實又上去了。
直接訪問本地壓測程序查詢接口,結果響應很快,不存在查詢緩慢的情況;使用Web頁面查詢,偶爾結果響應很慢。
當把壓測程序關閉后,端口連接建立數量恢復正常,此時查詢未再出現變得十分緩慢的情況。
猜測是因為后端開啟了多個連接線程池,每個線程池在每臺Coordinater建立的連接數量不同。當在Web進行查詢時,隨機被發往8臺機器中任意一臺,然后任意一臺又將請求發往集群中4臺Coordinater的任意一個。
而某臺機器的連接池中Connection建立數量較少,新請求過來需要建立新的連接,但當前Impala Connection 已有連接數超過最大連接數,因此getConnection阻塞等待成功獲取到連接。其中阻塞等待超時時間與--accepted_client_cnxn_timeout參數有關。
四、問題解決
核心其實就兩點,增大集群最大連接數 或者 減小應用連接池最大值大小,最終目的是使得 服務機數量*連接池最大連接數 <= Impala機器最大連接數。
具體操作:
- 應用連接池端:
- 減少應用端開啟連接數量,即降低連接池最大連接數(需要注意連接數與性能間的平衡點)。
- 縮小acquireIncrement參數,減小每次需要創建新連接時,額外創建的連接數量。
- 關閉超過最小連接數的閑置連接,通過設置maxIdleTimeExcessConnections可實現。
- 縮小acquireRetryAttempts參數,避免過多重試導致請求遲遲不返回。
- Impala集群端:
- 修改--fe_service_threads參數,用于調大Impala端最大連接數,使其等于 服務機器數* 最大線程數。
- 縮小--accepted_client_cnxn_timeout參數,以縮短當集群達到最大連接數后 客戶端需創建新連接時等待的超時時間。
- 縮小--disconnected_session_timeout參數,以便快速清除斷開連接的會話。如果客戶端在沒有驅動程序明確關閉會話的情況下斷開連接(例如,由于網絡故障),斷開連接的會話和與其關聯的查詢可能保持打開狀態并繼續消耗資源,直到斷開連接的會話超時,因此該參數值不適合過大。
啟示:
- 對于第三方工具,了解其可調參數 和 默認數值是必要的
- 第三方工具默認參數不一定是最優的,要根據自己應用的情況去調整
- 增加服務部署機器時,需要注意對集群增大的負載壓力,尋找擴大集群最大連接數量 和 查詢性能直接的平衡點
- 合理設置應用程序連接池大小及閑置拋棄等參數
五、附錄
1.資料
Apache Impala:https://impala.apache.org/docs/build/html/topics/impala_client.html
C3P0文檔:https://www.mchange.com/projects/c3p0-versions/c3p0-0.9.5.2/#maxConnectionAge
2.C3P0相關參數
3.Impala機器相關參數
總結
以上是生活随笔為你收集整理的问题排查 —— OLAP平台获取查询引擎连接严重耗时的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 调用移动端“搜索”按键,触发后收起软键盘
- 下一篇: 需求分析挑战之旅(疯狂的订餐系统)(1)