GaussDB重要通信參數匯總（gaussdb協議分析）

1???????? 問題背景

在GaussDB通信運維中，很多情況是由于一些參數配置的不合理導致集群效率低、資源過載、連接異常等問題。對于通信庫和操作系統兩方面都提供了大量可供用戶自定義的參數，熟練掌握一些重要的參數有助于快速定位現網通信故障問題。本文將關聯參數分組講述，便于大家更好的理解，若有差錯、遺漏，歡迎糾正、補充。詳細說明可見產品文檔。

2???????? 通信庫參數

2.1???????? tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_count

TCP是無感知的虛擬連接，中間斷開兩端不會立刻得到通知。一般在使用長連接的環境下，需要心跳?；顧C制感知其是否存活，從而減少無效連接，釋放資源。在操作系統級，提供了三個參數，可使用：sysctl –a | grep keepalive 查詢。

net.ipv4. tcp_keepalive_time = 7200? （默認7200）

net.ipv4.tcp_keepalive_intvl = 75???? （默認75）

net.ipv4.tcp_keepalive_probes = 9??? （默認9）

其表示如果一個連接上7200s后沒有任何數據發送，則設置了keepalive的一端會向對端發送keepalive?；顖笪?，會有三種結果：

對端回復ACK。則本端TCP認為該連接依然存活，繼續等待7200s后再發送keepalive報文；

對端回復RESET。說明對端進程已經重啟，本端應用程序應該關閉該連接；

沒有對端的任何回復。則本端重試，當重試9次后，每次重試間隔75s，仍然不可達，則向應用程序返回錯誤信息ETIMEOUT。

GaussDB中提供的這三個參數可以根據環境自定義，默認值均為0，期值望為：

tcp_keepalives_idle = 30

tcp_keepalives_interval = 30

tcp_keepalives_count = 9

2.2???????? comm_max_datanode、comm_max_stream、comm_max_receiver

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

comm_max_stream表示TCP代理通信庫支持的最大并發stream數量，默認值為1024，最大為60000，此參數要保證大于并發數*每并發平均stream算子數*（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找到對應的語句，修改以解決問題。

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

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

2.3???????? enable_stateless_pooler_reuse、comm_cn_dn_logic_conn

在pooler連接池通信模型中，客戶端通過gsql新建會話后，postmaster線程會fork一個postgres線程用于數據的交互，其與相應的agent線程連接。若開啟了pooler復用，即參數enable_stateless_pooler_reuse，可在pooler中根據database查找空閑的pool，直接獲取連接使用即可；若未開啟，則需要匹配user_name、database和pgoptions。在現網問題中，若出現連接數達到max_connections時，可以考慮清理空閑連接或開啟pooler復用。

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

值得注意的是，這兩個參數都需要在CN和DN上同步設置，否則會導致集群不能正常通信。

2.4???????? comm_quota_size、comm_usable_memory

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

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

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

3???????? 操作系統參數

TCP協議中包含了11種不同的狀態，TCP連接會根據發送或者接收到的消息轉換狀態，若服務器中存在大量的異常狀態，則會嚴重占用系統資源。操作系統提供了很多內核參數幫助用戶進行合理管控。

3.1???????? net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle、net.ipv4.tcp_max_tw_buckets

客戶端主動斷開連接，收到對端的確認后，狀態變為TIME_WAIT。TCP協議規定TIME_WAIT狀態會一直保持2MSL（最長報文段生存期，60秒），確保舊的連接狀態不會對新連接有影響。處于TIME_WAIT狀態的連接占用資源不會被內核釋放，所以作為服務器，在可能的情況下，盡量不要主動斷開連接，以減少TIME_WAIT狀態造成的資源浪費。

GaussDB設立了pooler緩存池，將空閑的TCP連接保留，方便客戶端下次快速建連。然而對于高并發的情況，在斷連時，pooler達到緩存上限直接釋放，CN主動斷開連接，此時會產生大量TIME_WAIT狀態（釋放的并發數*DN數）。此外，clean connection、DN之間的斷連等情況均會導致此問題。

net.ipv4.tcp_tw_reuse表示開啟重用，允許將TIME_WAIT狀態的sockets重新用于新的TCP連接，默認為0，GaussDB基線為1。開啟后，主動斷連一方可在1s內回收。

net.ipv4.tcp_tw_recycle表示開啟TCP連接中TIME_WAIT狀態下的sockets快速回收，默認為0，GaussDB基線為1。由于數據庫處于內網環境，開啟后在3.5*RTO（Retransmission Time Out，重傳超時時間）時間內回收，比tw_reuse稍快。

這兩個參數均依賴net.ipv4.tcp_timestamps開啟情況，操作系統默認開啟，但實際仍需核查，否則reuse和recycle均會失效。此外還需保證各服務器的timestamp一致，否則連基本的TCP建連可能都無法成功。

此外，tcp_max_tw_buckets表示系統允許并發的TIME_WAIT的最大數量，默認180000，GaussDB基線為10000。當實際數量超過此值時，系統會將過多的清除掉，并打印日志time wait bucket table overflow。

3.2???????? net.ipv4.tcp_syn_retries、net.ipv4.tcp_synack_retries

TCP建連時需要進行三次握手操作，對于每一次握手避免因環境問題導致丟包，都設置了重傳機制。

客戶端向服務器端發送SYN請求建連后進入SYN_SENT狀態，此時等待服務器端回復SYN+ACK，若超時未收到，則重傳SYN，達到net.ipv4.tcp_syn_retries后放棄建連。由于第n次等待的時間=2的n-1次冪，總的超時等待時間=2的net.ipv4.tcp_syn_retries次冪-1，因此參數過大會造成長時間等待，而過小可能因環境偶發問題導致建連失敗，GaussDB基線為5。

服務端收到客戶端發來的SYN，回復SYN+ACK后，進入SYN_RCVD狀態，此時還需等待客戶端回復ACK，若超時未收到，則重傳SYN+ACK，達到net.ipv4.tcp_synack_retries后放棄，建連失敗。同理，此參數也決定著總的超時等待時間，GaussDB基線為5。

3.3???????? net.ipv4.tcp_retries1、net.ipv4.tcp_retries2

net.ipv4.tcp_retries1目前的解釋有兩種，第一種為放棄回應一個TCP連接請求前，需要進行多少次重試（描述的很模糊，暫時還未想到場景）。另一種表示當重傳次數達到此值，TCP向IP層發送指令進行MTU探測、刷新路由等過程，避免由于網絡鏈路發生變化而導致TCP傳輸失敗。

net.ipv4.tcp_retries2表示的是TCP嘗試重傳數據的最大次數，實際中可能未達到此值便放棄了重傳并關閉連接。在設置此值后，操作系統內核會計算出一個timeout，其中對于ESTABLISHED狀態下的rto_base為200ms，TCP_RTO_MAX為120000ms。若第一次超時重傳時間為1.5s，后每一次重傳時間間隔為上次間隔的2倍，當總的超時時間大于timeout時，則立即放棄重傳，連接斷開。例如，設置tcp_retries2等于8，則計算出timeout等于102.2s。重傳第1次時間間隔為1.5s，下一次為3s，再下一次為6s，以此類推。當到第7次時為96s，與前6次之和為190.5s，大于102.2s，則第7次重傳放棄，連接斷開。GaussDB基線為12，計算得timeout等于564.6s，9.41min。

1.? if?(tcp_retries2?<=?9)

2.? ????timeout?=?((2?<

3.? else

4.? ????timeout?=?((2?<

5.? ????????(tcp_retries2?-?9)?*?TCP_RTO_MAX;

3.4???????? net.core.rmem_default、net.core.rmem_max、net.ipv4.tcp_rmem

net.core.rmem_default表示TCP數據接收窗口默認大小

net.ipv4.tcp_rmem表示為自動調優定義socket使用的接收內存，有三個值，第一個表示socket接收緩沖區分配的最少字節數

4???????? 定位手段

ping、netstat、ifconfig、sar等命令以及gsar.sh工具可快速幫助我們檢測網絡環境是否正常，若排除環境問題后，可優先考慮資源利用和參數配置問題。常用的命令有：

網絡設備狀態信息：sar –n DEV t n，t表示采樣時間間隔，n表示采樣次數；

tcp重傳：netstat -anop|grep “on(”|sort -rnk 3|head 50

網絡監控工具： ? ? ? ? ? gsar.sh

此外，很多參數配置問題報錯很明顯，這也是最容易進行定位的。例如2.2中提到的“Cannot get stream index, maybe comm_max_stream is not enough”。然而，問題的根因可能不在于此，貿然的修改參數會有效果，但這也可能僅僅是短暫的。此時，可以根據日志進行細致的分析，常用的視圖有：

stream

相關視圖：pgxc_comm_status、pgxc_comm_send_stream

相關參數：comm_max_stream

connection

相關視圖：pgxc_stat_activity

相關參數：max_connectios、enable_stateless_pooler_reuse、comm_cn_dn_logic_conn

memory

相關視圖：pv_total_memory_detail

相關參數：comm_quota_size、comm_usable_memory

針對不同的資源利用情況，找到出現問題sql語句或者進行相應的合理的調參是解決問題的根本辦法。

5???????? 常見案例

5.1???????? tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_count

問題來源：

問題描述：集群執行查詢操作，報流異常錯誤：ERROR: dn_6019_6110: failed to read response from Datanodes. Detail: 1039 Abnormal stream state

定位過程：

分析異常日志信息，可知出現異常是因為節點間的stream連接（邏輯連接）被關閉；

通過查找被關閉連接的對端node[4]的日志，發現邏輯連接被關閉的原因是socket（物理連接）被關閉了；

查看報錯日志信息，“Poller receive error: event[25]”中的“event[25]”是操作系統的報錯，表示連接已經斷開或者hang住，操作系統默認會對socket檢測有效性；

繼續觀察發現存在明顯的丟包。操作系統的keepalive在發送3次socket是否有效檢測時產生丟包，導致系統誤認為socket異常，關閉了socket。

解決詳情：將參數修改為期望值后，提升了操作系統檢測socket是否斷開的次數和檢測間隔，問題解決。

5.2???????? comm_max_datanode

問題來源：http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=53752

問題描述：擴容初始化實例和服務報錯，Gauss-52631: Invalid value for GUC parameter comm_max_datanode: 512

產品版本：GaussDB 200 8.0.0.1

解決詳情：擴容后實際DN數量大于comm_max_datanode的值，手動修改CN和DN上的參數，gs_guc reload –Z coordinator –Z datanode –N all –I all –c “comm_max_datanode=1024”。

5.3???????? comm_max_stream

問題來源：http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=53607

問題描述：業務報錯Cannot get stream index, maybe comm_max_stream is not enough

產品版本：GaussDB Elk 7.1.0.SP5

解決詳情：現場comm_max_stream參數默認值為1024，在正常跑批時查詢select node_name, remote_name, count(*) from pgxc_comm_send_stream group by 1, 2 order by 3 desc limit 100;得到DN間stream數量大約有600~700，當跑批時如果有臨時查詢，就會超過上限，導致報錯。將此參數調整到2048，問題解決。

5.4???????? enable_stateless_pooler_reuse

問題來源：http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=38882

問題描述：XX測試集群報錯：remaining connection slots are reserved for non-replication system admin connections

產品版本：GaussDB 200 LibrA V100R002C80SPC312

解決詳情：該報錯原因是由于DN連接達到max_connections=1000最大上限，再次獲取給系統內部預留的連接時報錯。通過對比guc參數，確認是由于該集群中enable_stateless_pooler_reuse參數為off，pooler連接無法復用導致，修改參數為on后解決。

6???????? 總結

本文講述了通信庫中幾個重要的參數，在現網各種各樣的場景下，這些參數相互影響制約，其合理配置尤為重要。此外，熟悉這些參數可能引發的一些問題，也為快速定位定位通信問題提供了一種手段。在日后的版本開發中，期望系統可以對這些參數提供動態配置，這樣可以減少很多不合理配置導致的問題，同時也能更加高效、合理的利用資源，從而提升數據庫的效率。

EI企業智能 Gauss AP 數據倉庫服務 GaussDB(DWS)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。