本文分享自華爲雲社區《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線程爲接收線程，發送端邏輯如下：
- send queue：producer發送線程將要發送的數據先push到一個無鎖隊列中，push完成之後，producer線程就可以繼續做自己的事情了
- send proxy thread：通信存在一個發送端代理線程，會統一將無鎖隊列中的數據，通過物理連接發送到對端
接收端邏輯如下：
- receive proxy thread：通信存在一個接收端代理線程，會統一將無鎖隊列中的數據，通過物理連接接收回來，解析數據包頭之後，放到對應線程的buffer池中
- 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不足問題，可以考慮三種解決方案：
新版本直接使用pgxc_comm_status視圖查看DN的stream使用情況：select node_name, stream from pgxc_comm_status order by 2 desc;
在CN上查詢當前任意兩個DN之間的stream情況：select node_name, remote_name, count(*) as stream from pgxc_comm_send_stream group by 1, 2 order by 3 desc limit 30;
若當前業務恢復， 可使用腳本對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.參考連接
- GaussDB重要通信參數彙總：https://bbs.huaweicloud.com/blogs/239863
- 【帶你走進DWS大集羣內幕】大集羣通信：作業hang、殘留問題定位：https://bbs.huaweicloud.com/blogs/407719
- GaussDB(DWS) 集羣通信系列三：集羣通信常用視圖：https://bbs.huaweicloud.com/blogs/209112
- GaussDB（DWS）通信庫libpq重構介紹（一）：https://bbs.huaweicloud.com/blogs/289336
- GaussDB（DWS）通信庫libpq重構介紹（二）：https://bbs.huaweicloud.com/blogs/297955