GaussDB(DWS)网络流控与管控效果

举报
门前一棵葡萄树 发表于 2023/04/03 11:23:01 2023/04/03
【摘要】 上一篇博文GaussDB(DWS)网络调度与隔离管控能力,我们详细介绍了GaussDB网络调度逻辑,并简单介绍了如何应用网络隔离管控能力。本篇博文主要介绍GaussDB(DWS)网络流控能力,并对其管控效果进行验证。 一、网络过载影响分析网络过载对性能的影响主要体现在两方面:网络调度对性能的影响,性能影响原因分析与GaussDB网络调度详见博客:GaussDB(DWS)网络调度与隔离管控能力...

上一篇博文GaussDB(DWS)网络调度与隔离管控能力,我们详细介绍了GaussDB网络调度逻辑,并简单介绍了如何应用网络隔离管控能力。本篇博文主要介绍GaussDB(DWS)网络流控能力,并对其管控效果进行验证。 

一、网络过载影响分析

网络过载对性能的影响主要体现在两方面:

  1. 网络调度对性能的影响,性能影响原因分析与GaussDB网络调度详见博客:GaussDB(DWS)网络调度与隔离管控能力
  2. 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缓存对业务性能的影响,测试环境配置如下:

参数名称 参数配置
/proc/sys/net/ipv4/tcp_wmem min/default/max: 4096/16384/4194304(默认配置)
/proc/sys/net/ipv4/tcp_rmem min/default/max: 4096/87380/6291456(默认配置)
网卡 10GE
CPU 72核
内存 350GB
集群 3节点12DN

使用大表broadcast作为背景压力,两个表简单关联作为正常业务进行测试,测试数据如下:

测试场景 执行时间 性能裂化(ms)
无背景压力(基准数据) 5ms ---
有背景压力,无网络管控 679ms 674ms
有背景压力,背景压力降级(不流控) 367ms 362ms

注:为了更直观地体现TCP缓存对性能的影响,我们使用相对无背景压力增加的执行时间作为性能裂化指标。

背景压力测试过程中TCP缓存持续高达2MB以上,从上述测试数据看,单纯的网络调度无法彻底解决网络过载对业务性能的影响。其他环境参数不变,测试TCP缓存对性能的影响:

TCP缓存(tcp_wmem/tcp_rmem配置相同) 有背景压力,无网络管控 有背景压力,背景压力降级(不留控)
min/default/max: 51200/51200/51200 403ms 12ms
min/default/max: 102400/102400/102400 439ms 17ms
min/default/max: 512000/512000/512000 573ms 77ms

从上述测试数据以及TCP缓存默认配置的测试数据看,无论是否进行网络管控,都是TCP缓存越大,性能越差。到这里我们基本可以确定,网络过载场景下应用网络调度后,TCP缓存是性能影响的关键点,但是直接调整TCP缓存区配置会影响到网络整体吞吐量和通信延迟,因此需要采用其他技术控制TCP缓存大小在一定范围内。

二、GaussDB网络流控

2.1 网络限流算法

限流是保护系统稳定的三把利器(限流、缓存、降级)之一。限流可以是限制并发,也可以是限制资源使用;可以保护自己,也可以保护别人。数据库混合负载场景下,限流可以防止低优业务占用过多资源,预防资源过载,保证高优业务性能不受大幅影响。常见的限流算法有计数限流、漏桶算法和令牌桶算法:

  1. 计数限流:通过对一个限流周期内的请求数量进行限制,实现限流的目的。在一个限流周期内,可以限制请求不超限,但是在两个限流周期的相邻时间,存在临界问题,可能出现瞬时流量超限的情况。
  2. 漏桶限流:按照固定速率消费请求,限制单位时间内可以发送的请求量;请求先放入桶(队列)中,漏桶按照固定速率出水,可以防止突发流量。
  3. 令牌桶限流:服务提供者按照固定速率向令牌桶中加入令牌,令牌总量达到阈值则不再添加;请求消费时从令牌桶中获取一定数量令牌,如果令牌不足,则触发拒绝策略,令牌桶允许短时突发流量。

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,在此基础上低优队列带宽配置越低,限流效果越好,对高优业务性能影响也就越小。

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);
insert into wt1 select generate_series(1,100000), generate_series(1,100000), repeat('a',900), repeat('b',6888);
create table wt3_join as select * from wt1 limit 10 ;
create table wt3 like wt1 with (orientation = column);
insert into wt3 select * from wt1; // 连续执行多次,导入3GB以上数据

// 高优业务SQL使用的表
CREATE TABLE wt11(c1 int, c2 int, b1 char(1000), b2 char(7000)) distribute by hash(c1);
CREATE TABLE wt12(c1 int, c2 int, b1 char(1000), b2 char(7000)) distribute by hash(c1);
INSERT INTO wt11 select generate_series(1,10000), generate_series(1,10000),repeat('a',900), repeat('b',6888);
INSERT INTO wt12 select * from wt11;
  • 使用以下SQL作为背景压力
select /*+ broadcast(wt3)*/ * from wt3 join wt3_join on wt3.c1=wt3_join.c1;
  • 使用以下SQL作为高优业务进行性能测试验证
select count(1) from (select /*+ broadcast(wt11)*/ wt11.c1,wt11.c2 from wt11, wt12 where wt11.c2 = wt12.c2);
  • 测试不同网络背景压力情况下(并行不同数量的背景压力SQL),分别测试无网络管控和背景压力降级的性能数据,记录SQL执行完成时间。
测试场景 无背景压力 1个背景压力 3个背景压力 5个背景压力 10个背景压力
无网络管控 5.048 86.197 165.397 206.677 278.875
背景压力降级 5.048 11.031 10.952 10.64 12.045
降级后性能提升 --- 75.166 145.445 196.037 266.83

从性能测试数据可以看出:

  • 不进行网络管控,网络过载情况下,业务性能裂化明显,其中10个背景压力下裂化达55倍。

  • 不进行网络管控情况下,网络背景压力越大,业务性能越差。

  • 背景压力降级后,不同背景压力情况下,业务性能变化不明显。

  • 背景压力降级后,业务性能裂化基本可控,不再大幅裂化。

背景压力降级后,业务性能还是有化,主要原因是流控只能降低TCP缓存,而不能完全消除,想要完全消除背景压力对业务性能的影响,可以配合使用终止异常规则,在识别网络欠佳SQL后将其终止

从测试验证效果看,降级异常规则配合低优队列网络流控,可以有效控制背景压力对业务性能的影响,保证网络欠佳SQL不会导致高优业务性能大幅

参考:

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

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

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。