12 KiB
TSG.BJ环境：Shaping测试相关问题
| ID | Creation Date | Assignee | Status |
|---|---|---|---|
| OMPUB-1068 | 2023-11-30T18:15:45.000+0800 | 冯伟浩 | 已关闭 |
TSG界面：https://192.168.44.29/ Shaping策略ID：3776 !screenshot-1.png|thumbnail! !screenshot-2.png|thumbnail!
测试问题1：带宽分配不均 描述：使用3个电脑共享15Mbps带宽测试Fair Share。只有一个电脑下载的时候速度在1600-1800KB/s，带宽占用正常；加入第二台电脑下载，下载速度变为每台电脑各800+KB/s，带宽占用正常；加入第三台电脑下载，理论上应该是每台500-600KB/s，但实际上只有偶尔几秒会比较均匀，大多数情况是一台800-900KB/s，一台400-500KB/s，一台200+KB/s，带宽明显分配不均匀 （截图待复测补充）
测试问题2：使用迅雷或百度网盘下载，下载速度与Shaping显示带宽有明显差异 描述：使用迅雷或百度网盘下载时，下载速度2.5MB-5MB/s，明显高于15Mbps带宽的下载速度，但Shaping策略中显示带宽仍未15Mbps !screenshot-3.png|thumbnail! !screenshot-4.png|thumbnail! !screenshot-5.png|thumbnail! liuchang commented on 2023-12-01T10:14:12.215+0800:
迅雷限速不准确为已知问题https://jira.geedge.net/browse/TSG-14287
按链接bug中评论方法，增加一条源目的地址相反的策略之后，限速正常
liuchang commented on 2023-12-01T10:14:52.909+0800:
请[~fengweihao] 帮忙看下fair share分配不准确的问题
zhangzhihan commented on 2023-12-01T11:12:55.278+0800:
问题1复测补充截图： !screenshot-6.png|thumbnail! !screenshot-7.png|thumbnail! !screenshot-8.png|thumbnail!
问题2复测结果： 添加一条源目的地址相反的策略之后，迅雷限速正常
fengweihao commented on 2023-12-01T11:46:29.067+0800:
环境介绍：
- shaping-engine地址：192.168.40.62
- shaping-sentinel地址：192.168.44.29
关于fair share本地单元用例测试： * {code:java} ./CRDT_tb_gtest --gtest_filter=Weight Note: Google Test filter = Weight [==========] Running 2 tests from 1 test case. [----------] Global test environment set-up. [----------] 2 tests from FairTokenBucket [ RUN ] FairTokenBucket.Weight class weight demand allocated ideal 1 1 20000 4006 4008 2 1 20000 4008 4008 3 1 20000 4007 4008 4 1 20000 4006 4008 5 1 20000 4007 4008{code}
目前当前环境存在问题：
- shaping-engine上查看FTINFO tsg-shaping-1024-incoming，ActiveMembers正常
{code:java} 192.168.40.62:31323@tsg-shaping-vsys1> FTINFO tsg-shaping-1024-incoming 13) "ActiveMembers" 14) (integer) 3 {code}
- shaping-sentinel上查看FTINFO tsg-shaping-1024-incoming，ActiveMember存在异常
{code:java} 192.168.44.29:5211@tsg-shaping-vsys1> FTINFO tsg-shaping-1024-incoming 13) "ActiveMembers" 14) (integer) 10{code}
shaping-engine和shaping-sentinel之间同步存在问题，但是shaping-sentinel不经过流量，因此同步方向只有shaping-engine向shaping-sentinel同步
关于fair share分配不均问题：
- 请刘畅补充，10版调用ftconsume_command的处理逻辑，方便使用Swarmkv Node本地复现
liuchang commented on 2023-12-01T11:56:33.461+0800:
该设备上运行的shaping版本为1.3.6
该版本实现为：
为减少swarmkv调用次数，当session中缓存token不足时，向swarmkv请求当前包大小10倍的token，多余的token缓存到session中；需要确认该获取10倍大小token的行为是否对fair-share算法产生影响
fengweihao commented on 2023-12-04T10:47:23.579+0800:
Swarmkv Node本地测试：
本地验证：
- simple_node-5210 模拟shaping-sentinel执行FTCFG
- simple_node-5211 模拟shaping-engine执行FTCONSUME
每10微妙调用FTCONSUME调用100万次，执行逻辑模拟shaping * {code:java}
./simple_node -n demo -h 127.0.0.1:5211 -t 1 -r 1 --exec mult ftcfg command
192.168.58.221 Consumed Token:745723728, Wasted loop 264924 192.168.58.162 Consumed Token:741145392, Wasted loop 265343 192.168.58.103 Consumed Token:729808560, Wasted loop 266383 {code}
{code:java} 127.0.0.1:5210@demo> FTINFO ftb-token 13) "ActiveMembers" 14) (integer) 3{code}
{code:java} 127.0.0.1:5211@demo> FTINFO ftb-token 13) "ActiveMembers" 14) (integer) 3 {code}
本地验证：
- 在Weight一致的情况下，不同Member获取Token的比例是1:1，由于在真实使用情况下，不同Member获取Token的次数存在差异。需要在测试环境下复现上述问题
liuchang commented on 2023-12-05T18:29:35.554+0800:
本地测试，创建类型为max-min-fairness类型的一个profile，fair-factor为1，使用3个源ip测试
测试环境，192.168.44.47（shaping-sentinal），192.168.41.63（TSGX）
复现步骤
1.三个源IP同时打流量，44.47和41.63上通过FTINFO查看，ActiveMembers均为3
2.停止流量，修改fair-factor为2，重新使用同样ip打流量，44.47和41.63上查看ActiveMembers为6
补充测试
1.三个源IP同时打流量，44.47和41.63上通过FTINFO查看，ActiveMembers均为3
2.停止流量，不修改fai-factor，重新使用同样ip打流量，44.47和41.63上查看ActiveMembers为3
以上两个测试过程中，流量分配不均问题均存在且与bug描述中一致
fengweihao commented on 2023-12-05T18:54:20.702+0800:
推测问题如下：
- !image-2023-12-05-18-41-19-436.png|width=705,height=113!
问题分析：
- 由于ST_hyperloglog使用weight做为下标，在第一调用ftconsume_command时传入的weight为1，因此操作ftb->hll[0]， 修改fair-factor为2后，调用ftconsume_command时传入的weight为2，因此操作ftb->hll[1]，由于第一次ftb->hll[0]中数据未清空，因此造成上述ActiveMembers数据累加
liuchang commented on 2023-12-06T12:03:42.855+0800:
流量不均匀问题测试：
测试环境： 192.168.44.47（shaping_sentinal） + 192.168.41.63（tsgx）
max-min-fairness类型profile，fair-factor=1，3个源ip打流量，会概率性出现流量分配不均匀，5次尝试中能出现1到2次
测试环境：192.168.41.63（tsgx）单节点运行，手动创建key
max-min-fairness类型profile，fair-factor=1，3个源ip打流量，多次尝试流量都均匀
liuchang commented on 2023-12-06T15:42:51.495+0800:
补充测试，两个swarmkv节点，active member不统一
测试环境： 192.168.44.47（shaping_sentinal） + 192.168.41.63（tsgx）
max-min-fairness类型profile，fair-factor=1，3个源ip
操作步骤：
1.3个源IP打流量，FTINFO查看对应key，44.47和41.63上ActiveMembers均为3
2.停止所有流量，FTINFO查看对应key，44.47和41.63上ActiveMembers均为2，不再变化
3.重新使用其中一个ip打流量，FTINFO查看对应key，44.47上ActiveMembers为3， 41.63上ActiveMembers为1
gitlab commented on 2023-12-07T19:21:14.574+0800:
[郑超|https://git.mesalab.cn/zhengchao] mentioned this issue in [a merge request|https://git.mesalab.cn/swarmkv/swarmkv/-/merge_requests/65] of [swarmkv / swarmkv|https://git.mesalab.cn/swarmkv/swarmkv] on branch [bugfix-old-sthll-doesnot-slide|https://git.mesalab.cn/swarmkv/swarmkv/-/tree/bugfix-old-sthll-doesnot-slide]:{quote}The staggered HyperLogLog does not slide during queries and merges{quote}
fengweihao commented on 2023-12-08T11:40:33.417+0800:
TSG.BJ环境已通过手动方式更新，请复测
zhangzhihan commented on 2023-12-08T17:31:07.884+0800:
已复测，目前带宽分配仍不均。三台同时下载时，有一台几乎没有下载带宽。详情查看下文中的测试3内容 https://docs.geedge.net/pages/viewpage.action?pageId=120330513
gitlab commented on 2023-12-08T17:33:07.743+0800:
[冯伟浩|https://git.mesalab.cn/fengweihao] mentioned this issue in [a commit|b545d66dd2] of [TSG / tsg-os-buildimage|https://git.mesalab.cn/tsg/tsg-os-buildimage] on branch [update-libswarmkv-to-v4.0.3|https://git.mesalab.cn/tsg/tsg-os-buildimage/-/tree/update-libswarmkv-to-v4.0.3]:{quote}更新libswarmkv到v4.0.3, 版本修改: OMPUB-1068 shaping策略Fair Share限速问题{quote}
gitlab commented on 2023-12-08T17:33:24.880+0800:
[冯伟浩|https://git.mesalab.cn/fengweihao] mentioned this issue in [a merge request|https://git.mesalab.cn/tsg/tsg-os-buildimage/-/merge_requests/1987] of [TSG / tsg-os-buildimage|https://git.mesalab.cn/tsg/tsg-os-buildimage] on branch [update-libswarmkv-to-v4.0.3|https://git.mesalab.cn/tsg/tsg-os-buildimage/-/tree/update-libswarmkv-to-v4.0.3]:{quote}更新libswarmkv到v4.0.3, 版本修改: OMPUB-1068 shaping策略Fair Share限速问题{quote}
zhangzhihan commented on 2023-12-08T18:34:23.938+0800:
补充复测如下：
1、不下载，通过观看直播视频的方式测试带宽分配。 测试结果：测试结果不如下载动作具有参考性，因为直播视频的带宽并不是时刻占满的。两台终端同时观看直播（每台都开8-10个直播），带宽使用均抖动剧烈，无法判断是相互抢带宽的现象 或是 其中一台带宽占用不满释放的带宽的现象。
2、使用浏览器下载WeChat.exe。 测试结果： 1）两台同时下载时，出现明显的抢用带宽现象，表现为两台互相抢，一台占满另一台几乎没带宽，带宽占用抖动剧烈； !screenshot-9.png|thumbnail! !screenshot-10.png|thumbnail! 2）三台同时下载时，出现轻微的抢带宽现象，总体观察三台的带宽占用较为平稳，存在较小的抖动。 [^video.mp4]
liuchang commented on 2023-12-08T18:38:24.209+0800:
针对复测情况现场收集信息
1.上传流量大致均匀，下载流量不均匀，其中下载使用迅雷，为UDP
2.两台设备下载时，后台查看ActiveMembers，ip数量为3到5之间跳跃，实际下载效果流量分配不均匀
3.三台设备下载时，后台查看ActiveMembers，ip数量为3到6之间跳跃，实际下载效果流量分配不均匀
猜测由于迅雷UDP下载，由于udp端口大小导致一部分目的IP被识别为源IP，导致ActiveMembers增多，流量分配不均匀
现场尝试使用浏览器下载 https://dldir1v6.qq.com/weixin/Windows/WeChatSetup.exe，下载TCP链接，收集信息如下
1.两台设备下载时，后台查看ActiveMembers，ip数量为2到3之间跳跃，实际下载效果两台设备互有争抢，抖动明显
2.三台设备下载时，后台查看ActiveMembers，ip数量基本为3，实际下载效果3台互有争抢，抖动比两台设备同时下载小很多
由于策略为3台设备的源IP，猜测两台设备同时下载时，第三台设备本身会产生少量流量，对流量均匀分配有影响
结论：
1.对于UDP链接，可能由于UDP端口大小问题导致源目的IP识别相反，造成源IP比实际多，影响fair-share分配效果
2.开发本地需进一步测试，当有两个IP下载且带宽占满时，第三个IP随机产生少量流量的情况下，带宽分配情况
liuchang commented on 2023-12-14T14:43:00.310+0800:
开发本地测试：fairness类型的profile
两个IP下载且带宽占满时，第三个IP随机产生少量流量，对两个下载IP的带宽分配不产生影响
两个IP同时下载时，两个IP在2s刷新的速率会有一些抖动（抖动大时两个IP速率大概相差2倍），但是在10秒和40秒的计算窗口内，总体带宽是均匀的
下图右侧从左到右4列分别为：累计字节数，2秒统计速率，10秒统计速率，40秒统计速率（使用工具为iftop）
!image-2023-12-14-14-49-43-787.png!
zhengchao commented on 2024-11-19T16:54:07.765+0800:
Issue closed due to no activity.
Attachments
47634/image-2023-12-05-18-41-19-436.png
47698/image-2023-12-14-14-49-43-787.png
47598/screenshot-1.png
47660/screenshot-10.png
47599/screenshot-2.png
47600/screenshot-3.png
47601/screenshot-4.png
47602/screenshot-5.png
47607/screenshot-6.png
47608/screenshot-7.png
47609/screenshot-8.png
47659/screenshot-9.png
47661/video.mp4