GaussDB(DWS)網路流控與管控效果-有解無憂

摘要：本文主要介紹GaussDB(DWS)網路流控能力，并對其管控效果進行驗證，

本文分享自華為云社區《GaussDB(DWS)網路流控與管控效果》，作者：門前一棵葡萄樹，

上一篇博文GaussDB(DWS)網路調度與隔離管控能力，我們詳細介紹了GaussDB網路調度邏輯，并簡單介紹了如何應用網路隔離管控能力，本篇博文主要介紹GaussDB(DWS)網路流控能力，并對其管控效果進行驗證，

一、網路過載影響分析

網路過載對性能的影響主要體現在兩方面：

網路調度對性能的影響，性能影響原因分析與GaussDB網路調度詳見博客：GaussDB(DWS)網路調度與隔離管控能力；
TCP快取對性能的影響，本篇博客主要分析TCP快取對性能的影響，并介紹GaussDB如何通過流控實作對TCP快取的控制，

眾所周知，TCP是一種面向連接的可靠的傳輸協議，為了保證資料傳輸的可靠，發送方發送的每一個資料包，接收方都需要向發送方回復一個應答，如果發送失敗，則進行重傳，上述機制保證了資料傳輸的可靠性，但是缺點也是比較明顯的：發送方每發送一個資料包都需要等待接收方確認，接收方確認接收后再發送下一個資料包，兩次發送之間的時間間隔取決于資料包收發時延和接收端處理能力，這個時間間隔越大，通信效率越低，為了解決這個問題，TCP引入了視窗的概念，所謂的視窗其實是作業系統開辟快取空間用于收發資料包快取，以提高通信效率，提升網路吞吐量，詳細原理可參考TCP滑動視窗機制，

TCP快取解決了TCP協議通信效率低的問題，但是網路過載情況下，TCP快取一般比較高，這就導致高優業務發送資料包時，需要等待快取區中資料全部發送完成后，才能發送高優業務的資料包，這個等待時間，我們稱之為發送時延，顯而易見，網路帶寬不變的情況下，TCP快取越大，發送時延也就越大，

假設網路帶寬1GB，TCP快取中有2MB資料，則TCP快取中資料全部發送出去的時間 = 2/1024*1000 = 1.95ms，考慮到接收方資料處理和應答時延，實際發送時延在2~4ms之間，如果高優作業每發送一個資料包都需要等待2~4ms的話，這個時間累積起來還是非常恐怖的，

實驗室環境下，構造網路過載場景，測驗TCP快取對業務性能的影響，測驗環境配置如下：

使用大表broadcast作為背景壓力，兩個表簡單關聯作為正常業務進行測驗，測驗資料如下：

注：為了更直觀地體現TCP快取對性能的影響，我們使用相對無背景壓力增加的執行時間作為性能裂化指標，

背景壓力測驗程序中TCP快取持續高達2MB以上，從上述測驗資料看，單純的網路調度無法徹底解決網路過載對業務性能的影響，其他環境引數不變，測驗TCP快取對性能的影響：

從上述測驗資料以及TCP快取默認配置的測驗資料看，無論是否進行網路管控，都是TCP快取越大，性能越差，到這里我們基本可以確定，網路過載場景下應用網路調度后，TCP快取是性能影響的關鍵點，但是直接調整TCP快取區配置會影響到網路整體吞吐量和通信延遲，因此需要采用其他技術控制TCP快取大小在一定范圍內，

二、GaussDB網路流控

2.1 網路限流演算法

限流是保護系統穩定的三把利器（限流、快取、降級）之一，限流可以是限制并發，也可以是限制資源使用；可以保護自己，也可以保護別人，資料庫混合負載場景下，限流可以防止低優業務占用過多資源，預防資源過載，保證高優業務性能不受大幅影響，常見的限流演算法有計數限流、漏桶演算法和令牌桶演算法：

計數限流：通過對一個限流周期內的請求數量進行限制，實作限流的目的，在一個限流周期內，可以限制請求不超限，但是在兩個限流周期的相鄰時間，存在臨界問題，可能出現瞬時流量超限的情況，
漏桶限流：按照固定速率消費請求，限制單位時間內可以發送的請求量；請求先放入桶（佇列）中，漏桶按照固定速率出水，可以防止突發流量，
令牌桶限流：服務提供者按照固定速率向令牌桶中加入令牌，令牌總量達到閾值則不再添加；請求消費時從令牌桶中獲取一定數量令牌，如果令牌不足，則觸發拒絕策略，令牌桶允許短時突發流量，

2.2 網路流控實作

GaussDB網路流控主要用于防止網路欠佳SQL引發網路持續過載，預防TCP快取持續飆高，引發網路發送延遲過大，進而導致高優業務網路請求不能及時發送，影響高優業務性能，對于正常業務并發過大導致的TCP快取飆高，建議采用查詢調度限制并發的方法進行解決，網路欠佳SQL的網路流控基于網路調度中的低優佇列設計實作，采用類漏桶演算法實作，

新增GUC引數low_priority_bandwidth（默認值：256MB）用于限制低優佇列可以占用的網路帶寬，這個引數有兩層含義（假設采用默認配置）：

低優佇列網路傳輸速率不超過256MB/s，
1ms內允許傳輸的資料量不超過256KB（256MB/s≈256KB/ms），保證TCP快取中低優佇列資料不超過256KB，防止低優佇列導致TCP快取過高導致高優業務性能大幅劣化，

低優佇列網路帶寬的設定需要充分考慮網路環境和集群部署情況，設定過大可能起不到網路流控效果，設定過小可能導致低優業務性能下降過大，例如10GE網路，3節點12DN環境，低優佇列網路帶寬不應高于256MB，在此基礎上低優佇列帶寬配置越低，限流效果越好，對高優業務性能影響也就越小；低優佇列網路帶寬配置接近網路上限情況下，網路欠佳SQL并發越大，限流效果越差，例如10GE網路，3節點12DN環境，低優佇列限流256MB情況下，大表broadcast并發15個以上時，網路限流效果開始下降，

2.3 流控效果驗證

測驗環境配置：

網卡：10GE
CPU：72核
記憶體：350GB
集群：3節點12DN，每個節點4個DN
low_priority_bandwidth：256

設定例外規則對查詢運行超過1min，且網路帶寬占用超過128MB（單DN，5s平均傳輸速率）的作業執行降級操作：

CREATE EXCEPT RULE bandwidth_rule1 WITH(bandwidth=128, ELAPSEDTIME=60, action='penalty');

創建資源池rp1，關聯上述例外規則：

CREATE RESOURCE POOL rp1 WITH(EXCEPT_RULE='bandwidth_rule1');

創建用戶user1關聯資源池rp1：

CREATE USER user1 RESOURCE POOL 'rp1' PASSWORD 'xxxxxxxx';

用戶user1執行查詢滿足“運行時間超過1min，且占用帶寬超過128MB”規則時，查詢被降級，降級后該查詢網路請求由低優佇列調度，

使用user1執行以下測驗驗證網路限流效果：

創建示例表并匯入資料

// 背景壓力SQL使用的表 
CREATE TABLE wt1(c1 int, c2 int, b1 char(1000), b2 char(7000)) distribute by hash(c1);
CREATE TABLE wt2(c1 int, c2 int, b1 char(1000), b2 char(7000)) distribute by hash(c1);
INSERT INTO wt1 select generate_series(1,10000), generate_series(1,10000),repeat('a',900), repeat('b',6888);
INSERT INTO wt2 select * from wt1;
INSERT INTO wt1 select * from wt1; // 連續執行多次，匯入3GB以上資料
// 高優業務SQL使用的表
CREATE TABLE wt3(c1 int, c2 int, b1 char(1000), b2 char(7000)) distribute by hash(c1);
CREATE TABLE wt4(c1 int, c2 int, b1 char(1000), b2 char(7000)) distribute by hash(c1);
INSERT INTO wt3 select generate_series(1,10000), generate_series(1,10000),repeat('a',900), repeat('b',6888);
INSERT INTO wt4 select * from wt3;

使用以下SQL作為背景壓力

select count(1) from (select /*+ broadcast(wt1)*/ wt1.c1,wt1.c2 from wt1, wt2 where wt1.c2 = wt2.c2);

使用以下SQL作為高優業務進行性能測驗驗證

select count(1) from (select /*+ broadcast(wt3)*/ wt3.c1,wt3.c2 from wt3, wt4 where wt3.c2 = wt4.c2);

測驗不同網路背景壓力情況下（并行不同數量的背景壓力SQL），分別測驗無網路管控和背景壓力降級的性能資料，記錄SQL執行完成時間，

從性能測驗資料可以看出：

不進行網路管控，網路過載情況下，業務性能裂化明顯，其中10個背景壓力下裂化達55倍，
不進行網路管控情況下，網路背景壓力越大，業務性能越差，
背景壓力降級后，不同背景壓力情況下，業務性能變化不明顯，
背景壓力降級后，業務性能裂化基本可控，不再大幅裂化，

背景壓力降級后，業務性能還是有劣化，主要原因是流控只能降低TCP快取，而不能完全消除，想要完全消除背景壓力對業務性能的影響，可以配合使用終止例外規則，在識別網路欠佳SQL后將其終止，

從測驗驗證效果看，降級例外規則配合低優佇列網路流控，可以有效控制背景壓力對業務性能的影響，保證網路欠佳SQL不會導致高優業務性能大幅劣化，

參考：

https://www.cnblogs.com/niumoo/p/16007224.html

https://xie.infoq.cn/article/4a0acdd12a0f6dd4a53e0472c

點擊關注，第一時間了解華為云新鮮技術~

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/551782.html

標籤：其他

上一篇：SQL Server事務執行程序中中釋放鎖導致的死鎖問題 - 排查與分析

下一篇：返回列表