目錄

• • 一、問題說明
  • 二、原因查明
  • • 1. 數(shù)據(jù)庫連接池
    • 2. Impala連接參數(shù)
    • 3. 應(yīng)用近期改動
    • 4. 集群中連接建立數(shù)量
  • 三、問題復(fù)現(xiàn)
  • 四、問題解決
  • 五、附錄
  • • 1.資料
    • 2.C3P0相關(guān)參數(shù)
    • • 3.Impala機器相關(guān)參數(shù)

一、問題說明

BI平臺出現(xiàn)了查詢時快時慢的問題，查看監(jiān)控發(fā)現(xiàn)獲取連接部分耗時飆升，相關(guān)監(jiān)控如下：

正常情況下獲取連接耗時P99都在100ms以內(nèi)，但是從某天開始，其耗時飆升到峰值時需要262k毫秒，嚴重拖慢了查詢耗時。

二、原因查明

1. 數(shù)據(jù)庫連接池

系統(tǒng)中使用的C3P0連接池，連接參數(shù)部分只設(shè)置了jdbcUrl、username、password、maxPoolSize和minPoolSize。 其中，maxPoolSize為20，minPoolSize為1。

2. Impala連接參數(shù)

Impala中fe_service_threads可以用來設(shè)置單個coordinater最大連接數(shù)，未對該參數(shù)作改動，默認為64，其具體含義為：

• fe_service_threads值分別對Beeswax pool（impala shell等）、Hive Server2pool（jdbc\hue等）生效，即當配置值為64時，表示該節(jié)點最大可支持128個客戶端連接，其中Beeswax pool 64個，hiveserver2 pool 64個；fe_service_threads配置是對節(jié)點（coordinater）而言地，如當集群存在2個coordinater節(jié)點，并且fe_service_threads的配置為64時，集群最大可提供256個客戶端連接；

• fe_service_threads限制包括空閑連接在內(nèi)的所有客戶端連接，并不是單位時間的查詢并發(fā)數(shù)。

• 同一時間connection和session的對應(yīng)關(guān)系是一一對應(yīng)地，當手動關(guān)閉session時，連接會在下一次查詢提交時重建session，不會引起錯。

• session關(guān)閉可能connection未關(guān)閉，session存在connection一定存在。

3. 應(yīng)用近期改動

由于公司最近推進容器化部署，第一階段需進行混合部署，即發(fā)布一定數(shù)量的容器化服務(wù)并且不下線已有虛擬機服務(wù)，因此提供服務(wù)的機器數(shù)量從4臺變?yōu)榱?臺。

4. 集群中連接建立數(shù)量

使用如下命令查看各IP在 Impala 查詢服務(wù)端口 21050（對于mysql則為3306）上建立連接數(shù)量情況。

sudo netstat -nat | grep 21050 | grep ESTABLISHED | awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn

總共8臺線上機器連接Impala集群，集群中有四臺Coordinater，查看發(fā)現(xiàn)每臺Coordinater 21050端口連接數(shù)量都在80及以上，這已經(jīng)超出了Impala最大連接數(shù)量了。

結(jié)合以上原因，推測是增加服務(wù)機器后引起，將提供服務(wù)的機器數(shù)量從8臺降低為4臺之后，線上服務(wù)獲取OLAP查詢引擎連接耗時回歸正常區(qū)間。

三、問題復(fù)現(xiàn)

開啟初始線程數(shù)64、最大線程數(shù)64、最小線程數(shù)64的服務(wù)，連接四臺Coordinater，這樣在發(fā)起查詢時會產(chǎn)生大量的Connection，使得端口連接建立數(shù)超過Impala集群單Coordinater最大允許連接數(shù)。
服務(wù)啟動后，查看監(jiān)控發(fā)現(xiàn)getConnection耗時確實又上去了。

直接訪問本地壓測程序查詢接口，結(jié)果響應(yīng)很快，不存在查詢緩慢的情況；使用Web頁面查詢，偶爾結(jié)果響應(yīng)很慢。

當把壓測程序關(guān)閉后，端口連接建立數(shù)量恢復(fù)正常，此時查詢未再出現(xiàn)變得十分緩慢的情況。

猜測是因為后端開啟了多個連接線程池，每個線程池在每臺Coordinater建立的連接數(shù)量不同。當在Web進行查詢時，隨機被發(fā)往8臺機器中任意一臺，然后任意一臺又將請求發(fā)往集群中4臺Coordinater的任意一個。

而某臺機器的連接池中Connection建立數(shù)量較少，新請求過來需要建立新的連接，但當前Impala Connection 已有連接數(shù)超過最大連接數(shù)，因此getConnection阻塞等待成功獲取到連接。其中阻塞等待超時時間與--accepted_client_cnxn_timeout參數(shù)有關(guān)。

四、問題解決

核心其實就兩點，增大集群最大連接數(shù) 或者 減小應(yīng)用連接池最大值大小，最終目的是使得 服務(wù)機數(shù)量*連接池最大連接數(shù) <= Impala機器最大連接數(shù)。

具體操作：

• 應(yīng)用連接池端：
  • 減少應(yīng)用端開啟連接數(shù)量，即降低連接池最大連接數(shù)（需要注意連接數(shù)與性能間的平衡點）。
  • 縮小acquireIncrement參數(shù)，減小每次需要創(chuàng)建新連接時，額外創(chuàng)建的連接數(shù)量。
  • 關(guān)閉超過最小連接數(shù)的閑置連接，通過設(shè)置maxIdleTimeExcessConnections可實現(xiàn)。
  • 縮小acquireRetryAttempts參數(shù)，避免過多重試導(dǎo)致請求遲遲不返回。
• Impala集群端：
  • 修改--fe_service_threads參數(shù)，用于調(diào)大Impala端最大連接數(shù)，使其等于 服務(wù)機器數(shù)* 最大線程數(shù)。
  • 縮小--accepted_client_cnxn_timeout參數(shù)，以縮短當集群達到最大連接數(shù)后 客戶端需創(chuàng)建新連接時等待的超時時間。
  • 縮小--disconnected_session_timeout參數(shù)，以便快速清除斷開連接的會話。如果客戶端在沒有驅(qū)動程序明確關(guān)閉會話的情況下斷開連接（例如，由于網(wǎng)絡(luò)故障），斷開連接的會話和與其關(guān)聯(lián)的查詢可能保持打開狀態(tài)并繼續(xù)消耗資源，直到斷開連接的會話超時，因此該參數(shù)值不適合過大。

啟示：

• 對于第三方工具，了解其可調(diào)參數(shù) 和 默認數(shù)值是必要的
• 第三方工具默認參數(shù)不一定是最優(yōu)的，要根據(jù)自己應(yīng)用的情況去調(diào)整
• 增加服務(wù)部署機器時，需要注意對集群增大的負載壓力，尋找擴大集群最大連接數(shù)量 和 查詢性能直接的平衡點
• 合理設(shè)置應(yīng)用程序連接池大小及閑置拋棄等參數(shù)

五、附錄

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相關(guān)參數(shù)

---

---

---

---

---

---

---

---

3.Impala機器相關(guān)參數(shù)

---

總結(jié)

以上是生活随笔為你收集整理的问题排查 —— OLAP平台获取查询引擎连接严重耗时的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。