Libcomm通信庫：GaussDB(DWS) 為解決建聯過多的小妙招

本文分享自華為雲社區《GaussDB(DWS) 集群通信系列三：Libcomm通信庫》，作者： 半島里有個小鐵盒。

1.前言

適用版本：【8.1.0(及以上)】

在大規模集群、高併發業務下，如果有1000DN集群，每個stream線程需要建立1000個連接。如果1000 stream併發，DN總共需要建立100萬個連接，會消耗大量的連接、記憶體、fd資源。為瞭解決這個問題，我們引入了Libcomm通信庫，在一個物理長連接上模擬n個邏輯連接，使得所有併發的數據跑在一個物理連接上，極大的解決了物理連接數過多和建連耗時的問題。

2.基本原理

GaussDB(DWS)為解決建聯過多的問題，實現了Libcomm通信庫（即邏輯連接通信庫），在一個物理長連接上模擬n個邏輯連接，使得所有併發的數據跑在一個物理連接上。比如DN1需要給DN2發送數據，併發數1000，在原有邏輯下，DN1需要建立與DN2連接的1000個線程與之進行交互，消耗了大量的連接、記憶體、fd資源，而改造Libcomm通信庫之後，DN1與DN2僅需建立一個真正的物理連接，在這個物理連接上可以建立很多個邏輯鏈接，這樣可以使得1000個併發就可以用同一個物理連接進行數據交互。

那麼GaussDB(DWS)的邏輯連接是怎麼實現的呢？首先我們從連接數據流入手，挖掘其實現邏輯。

物理連接支持TCP、RDMA等協議連接，以TCP為例，其物理連接數據流可以分為兩部分，即數據包頭+數據。數據包頭為固定長度，其中包含邏輯連接號和數據塊長度，用來區別邏輯連接，並接收每個連接各自對應的數據。

瞭解了物理連接發送的數據流，那具體的發送邏輯是什麼樣的呢？其具體的流程如下圖所示：

上圖中producer線程為發送線程，consumer線程為接收線程，發送端邏輯如下：

1. send queue：producer發送線程將要發送的數據先push到一個無鎖隊列中，push完成之後，producer線程就可以繼續做自己的事情了
2. send proxy thread：通信存在一個發送端代理線程，會統一將無鎖隊列中的數據，通過物理連接發送到對端

接收端邏輯如下：

1. receive proxy thread：通信存在一個接收端代理線程，會統一將無鎖隊列中的數據，通過物理連接接收回來，解析數據包頭之後，放到對應線程的buffer池中
2. buffer1：consumer接收線程會從自己對應的buffer池中取出數據，執行自己的數據加工邏輯。

上述這個方法可能會存在一些問題，併發比較高時producer線程會一直往隊列里push，如果此時對端cunsumer1線程正在處理別的數據導致接收buffer1滿了的話，producer2和producer3無法往網路上填充更多的數據，發送階段就會阻塞，而此時可能consumer2和consumer3正在空閑狀態，等待這個接收數據，但是因為發送端阻塞而接收不到，這種場景會嚴重影響性能。這個模型我們稱之為push模型。因此我們需要通過另外一種流控機制來解決這個問題，我們稱之為pull模型。

• push模型：發送端不感知接收端狀態。一直往無鎖隊列中push，直到push阻塞。
• poll模型：發送端感知接收端狀態。發送端一開始不會發送數據，當接收端里的buffer池記憶體滿足一定條件時，通知對應的發送端，並告知可以接收的數據量，發送端可以按照對端可以接收的數據量進行發送。

通過poll模型的實現，在本線程阻塞的情況下，其他的線程不會阻塞，以確保物理連接中數據永遠不會阻塞，保證連接的通暢性。

3.相關視圖

3.1.pgxc_comm_delay

該視圖展示所有DN的通信庫時延狀態。

該視圖中的欄位包括節點名稱、連接對端節點的節點名稱、連接對端IP的對端地址、當前物理連接使用的stream邏輯連接數量、當前物理連接一分鐘內探測到的最小時延、當前物理連接一分鐘內探測道德平均值和當前物理連接一分鐘內探測到的最大時延。

3.2.pgxc_comm_recv_stream

該視圖展示所有DN上的通信庫接收流狀態。其中欄位包括節點名稱、使用此通信流的線程ID、連接對端節點名稱、連接對端節點ID、通信對端DN在本DN內的標識編號、通信流在物理連接中的標識編號、通信流所使用的tpc通信socket、通信流當前的狀態、通信流對應的debug_query_id編號、通信流所執行查詢的plan_node_id編號、通信流所執行查詢send端的smpid編號、通信流所執行查詢recv端的smpid編號、通信流接收的數據總量、通信流當前生命周期使用時長、通信流的平均接收速率、通信流當前的通信配額值、通信流當前緩存的數據大小。

3.3.pgxc_comm_send_stream

該視圖展示所有DN上的通信庫發送流狀態。其中欄位包括節點名稱、使用此通信流的線程ID、連接對端節點名稱、連接對端節點ID、通信對端DN在本DN內的標識編號、通信流在物理連接中的標識編號、通信流所使用的tpc通信socket、通信流當前的狀態、通信流對應的debug_query_id編號、通信流所執行查詢的plan_node_id編號、通信流所執行查詢send端的smpid編號、通信流所執行查詢recv端的smpid編號、通信流接收的數據總量、通信流當前生命周期使用時長、通信流的平均接收速率、通信流當前的通信配額值和通信流等待quota值產生的額外時間開銷。

3.4.pgxc_comm_status

該視圖展示所有DN的通信庫狀態。其中欄位包括節點名稱、節點通信庫接收速率，單位為byte/s、節點通信庫發送速率，單位為byte/s、節點通信庫接收速率，單位為Kbyte/s、節點通信庫發送速率，單位為Kbyte/s、cmailbox的buffer大小、libcomm進程通信記憶體的大小、libpq進程通信記憶體的大小、postmaster線程實時使用率、gs_sender_flow_controller線程實時使用率、gs_receiver_flow_controller線程實時使用率、多個gs_receivers_loop線程中最高的實時使用率、當前使用的邏輯連接總數。

4.相關GUC參數

4.1 comm_max_datanode

表示TCP代理通信庫支持的最大DN數，最小值為1，最大值為8192。當DN數小於256時，預設值為256；否則，為大於等於DN數的2的N次方。在集群擴容、縮容場景下，要註意此參數的變更。

4.2 comm_max_stream

表示TCP代理通信庫支持的最大併發stream數量，預設值為1024，最大為60000，此參數要保證大於併發數

（smp的平方），否則會報錯Cannot get stream index, maybe comm_max_stream is not enough。此外，在設置此參數時需要考慮占用記憶體問題，其大小為256byte * comm_max_stream * comm_max_datanode，可見在記憶體、comm_max_datanode和comm_max_stream三者之間需要一個動態的規劃。

針對comm_max_stream不足問題，可以考慮三種解決方案：

然而，還有情況是個別的SQL語句嚴重消耗stream，此時可以使用實時topsql或歷史topsql找到對應的語句，修改以解決問題。

4.3 comm_max_receiver

表示TCP代理通信庫接收端接收線程的數量，最大值為50，預設值為4。在大集群、大併發場景下，適當的調大該參數有利於提升查詢的性能；但如果通信層可用記憶體不足，線程間有競爭會對接收性能有負面影響。

註：SMP是指對稱多處理技術，資料庫領域的SMP並行技術一般指利用多線程技術實現查詢的並行執行，以充分利用CPU資源，從而提升查詢性能。SMP特性通過運算元並行來提升性能，同時會占用更多的系統資源，在使用時，需要根據使用場景與限制進行合理的配置。在GaussDB中，SMP功能由query_dop參數決定，預設值為1。

4.4 comm_cn_dn_logic_conn

對於256節點的集群來說，併發場景導致CN和DN之間存在大量連接，每個連接占用一個埠，則CN的埠號很容易受限。為解決此問題，設計了CN多流，即CN與DN之間採用邏輯連接。comm_cn_dn_logic_conn參數預設值是off，在集群規模或併發達到一定程度時，需要將其開啟為on，避免CN與DN之間由於埠號受限而無法建連。

4.5 comm_quota_size

TCP代理通信庫採用pull模式進行流量控制，避免消息堵塞。兩個DN分別有一個buffer，當一條通道發送端數據量過大時，很容易造成buffer填滿，阻塞了其他通道的發送。此時，對於每條通道設置一個quota，接收端根據buffer剩餘空間的大小發送給發送端一個合理quota值，發送端根據quota大小發送數據。

comm_quota_size表示每個通道單次不間斷發送數據量配額，預設值1MB。當通道發送數據量達到配額時，發送端等待接收端重新發送配額，進而繼續發送數據，從而實現流控功能。其取值為0時，表示不使用quota，在一些大流量等場景中，查詢之間可能會有影響。在1GE網卡環境中，受網卡能力限制，應該調小該參數，推薦20KB~40KB。如果環境記憶體充足，參數comm_usable_memory設置較大，可以適當調大，從而提升性能。

4.6 comm_usable_memory

commusable_memory表示的是TCP代理通信庫可使用的最大記憶體大小，預設值4000MB。此參數需要根據環境記憶體及部署方式具體配置，保證了系統不會因為通信層接收緩存造成進程記憶體膨脹。在單台機器上，通信占用記憶體最壞情況=部署節點個數* comm_usable_memory。考慮環境記憶體情況，此參數配置過小，會影響通信性能，過大則可能造成系統記憶體不足等問題。與comm_quota_size結合，進行合理的配置至關重要。

5.總結

本文詳細介紹了Libcomm通信庫及其原理，讓我們更好的理解GaussDB(DWS)集群通信中的具體邏輯，對於GaussDB(DWS)通信運維也具備一定的參考意義。

6.參考連接

1. GaussDB重要通信參數彙總：https://bbs.huaweicloud.com/blogs/239863
2. 【帶你走進DWS大集群內幕】大集群通信：作業hang、殘留問題定位：https://bbs.huaweicloud.com/blogs/407719
3. GaussDB(DWS) 集群通信系列三：集群通信常用視圖：https://bbs.huaweicloud.com/blogs/209112
4. GaussDB（DWS）通信庫libpq重構介紹（一）：https://bbs.huaweicloud.com/blogs/289336
5. GaussDB（DWS）通信庫libpq重構介紹（二）：https://bbs.huaweicloud.com/blogs/297955

點擊關註，第一時間瞭解華為雲新鮮技術~