共计 2278 个字符,预计需要花费 6 分钟才能阅读完成。
作者:刘安
爱可生测试团队成员,次要负责 DTLE 开源我的项目相干测试工作,善于 Python 自动化测试开发,最近醉心于 Linux 性能剖析优化的相干常识。
本文起源:原创投稿
* 爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。
背景条件:
- 应用 sysbench 压力工具对 10 张 1 万记录表进行增改删操作
- 应用 TC 工具来模仿高延时,低带宽场景
工具筹备:
1.tc # 模仿网络带宽受限以及减少提早
2.iperf3 # 验证网络带宽
3.sysbench # 制作数据压力
环境筹备:
1.DTLE 版本
3.20.10.0
2. 服务器
| IP | 用处 |
| ————- | ———— |
| 10.186.18.123 | 源端数据库 |
| 10.186.18.117 | 指标端数据库 |
| 10.186.63.20 | 源端 DTLE |
| 10.186.63.145 | 指标端 DTLE |
3. 在两台 DTLE 服务器上增加网络带宽限度以及减少提早(经测试网络提早配置只对发送无效,故须要在源端和指标端同时增加 TC 规定,每端提早配置为预期提早的一半)。
#!/usr/bin/env bash
# Name of the traffic control command.
TC=`which tc`
# The network interface we're planning on limiting bandwidth.
IF=eth0 # Interface
# Download limit
DNLD=2mbit # DOWNLOAD Limit
# Upload limit
UPLD=2mbit # UPLOAD Limit
# IP address of the machine we are controlling
IP=10.186.63.145 # Host IP
#IP=10.186.63.20
# Network latency
DELAY=125ms
# Filter options for limiting the intended interface.
U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32"
$TC qdisc add dev $IF root handle 1: htb default 1
$TC class add dev $IF parent 1: classid 1:10 htb rate $DNLD
$TC class add dev $IF parent 1: classid 1:20 htb rate $UPLD
$TC qdisc add dev $IF parent 1:10 handle 10: netem delay $DELAY
$TC qdisc add dev $IF parent 1:20 handle 20: netem delay $DELAY
$U32 match ip dst $IP/32 flowid 1:10
$U32 match ip src $IP/32 flowid 1:20
4. 验证配置失效
- DTLE 源端服务器 ping DTLE 指标端服务器
- DTLE 指标端服务器 ping DTLE 源端服务器
-
DTLE 源端到 DTLE 指标端网络带宽
- DTLE 指标端服务器
iperf3 -s
- DTLE 源端服务器
iperf3 -c 10.186.63.145
- DTLE 指标端服务器
-
DTLE 指标端到 DTLE 源端网络带宽
- DTLE 指标端服务器
iperf3 -s
- DTLE 源端服务器
iperf3 -c 10.186.63.145 -R
- DTLE 指标端服务器
5. 别离在服务器 10.186.63.20 和 10.186.63.145 部署 DTLE 组成集群
场景一:不同网络提早下数据库同步提早
- 网络带宽 2Mbits/s、数据压力 300QPS(binlog 产生速率为 1.47Mbit/s( 约 15GB/ 天)) 继续压测 120 秒
- 通过扭转 TC 脚本来模仿不同网络提早状况下对 DTLE 数据同步提早的影响
- job 配置中 GroupTimeout 的值为网络提早的 2 倍减 10ms(例如:网络提早为 100ms 则 GroupTimeout=190)
- job 配置中 GroupMaxSize 的值为 512000 (500KB)
注:图中复制提早为 120 秒压力测试中的最高复制延迟时间
小结:
1. 不同的网络延时,通过 DTLE 复制提早在 2 秒内
2. 非凡限度场景:
- 网络带宽有余的场景下,复制延时会线性增长
场景二:极限带宽下,MySQL 原生复制和 DTLE 压力比照
- 网络带宽 2Mbits/s、网络提早 250ms
- 在不产生线性递增复制提早的条件下,所能反对的最大数据压力
- job 配置中 GroupTimeout 的值为 490(网络提早的 2 倍减 10ms)
- job 配置中 GroupMaxSize 的值为 1024000 (1000KB)
- jbo 配置中 ReplChanBufferSize 的值为 600
注:718QPS 相当于每秒产生 452KB binlog(3.6Mbit/s),367 QPS 相当于每秒产生 231KB binglog(1.8Mbit/s)。
小结:
1. 在网络受限的条件下,MySQL 原生复制在 1.8Mbit/s 的压力下,达到最高压力
2. 在网络受限的条件下,DTLE 复制在 2.7Mbit/s 的压力下,达到最高压力
3.DTLE 利用分组和压缩,在网络受限场景下,能承载更高的复制压力,更好的适应窄带宽的场景
场景三:带宽不受限,MySQL 原生复制和 DTLE 应用带宽比照
- 网络提早 250ms、无带宽限度
- 在不同数据压力下,传输占用的网络带宽
- job 配置中 GroupTimeout 的值为 490
- job 配置中 GroupMaxSize 和 ReplChanBufferSize 的值随压力减少而增大
小结:
1. 实现等同数据量的传输复制,DTLE 相比 MySQL 原生复制提供更低的带宽占用;带宽占用率最高是 MySQL 原生复制的近 1/3。