内联解决方案
我们遇到了一个奇怪的问题，现在基本上没有想法：
我们为客户设置了一个 galera 集群（3 个节点 + MaxScale LB），他报告速度很慢。我们无法确定问题，因此我们设置了一个测试场景以深入挖掘：
- 我们将完整的集群 + 应用程序服务器克隆到一个单独的子网中，以防止当前用户的任何干扰
- 我们设法重现了缓慢：操作大约 10 秒
- 为了减少变量，我们在其中一个集群节点上安装了应用程序，以允许我们使用 db 连接到 localhost 进行测试
经过广泛的测试、调整和研究，我们决定在 VmWare ESX 上尝试相同的设置。所以我们将集群+应用程序迁移到 ESX 并进行了完全相同的测试 - 结果很奇怪......
从那里我们做了以下测试：
| 测试 | 结果 HyperV | 结果 ESX |
|---|---|---|
| 应用程序 -> 负载均衡器 | 10s | 6s |
| 应用程序 -> 直接数据库（本地主机） | 6.5s | 3,6s |
| App -> Direct DB（其他节点） | 9s | 5s |
| 应用程序->本地主机；没有集群 | 1.5s | 1.3s |
| 应用程序 (HyperV) -> LB (ESX) | 13s |
我们尝试的结果没有任何实际变化：
- 将所有集群节点移动到相同的硬件上
- 在循环和读写拆分之间切换 maxscale
- 应用各种 mariadb/galera 设置
- 在 hyperV 中应用了各种设置
以下设置：
- HyperV Windows 服务器 2019
- Ubuntu 20.04 上的 MariaDb
- 全闪存高清
- 16GB 光纤通道
- 间网卡
- 主机（实际上是虚拟机）上的负载可以忽略不计
我们完全被难住了，因为我们无法解释为什么 hyperV 和 ESX 之间的时序差异如此之大。我们认为它一定是网络 IO，但无法确定哪个设置有问题。
从数字/测试中，我们可以断定哪些部分没有故障：
- HD/IO：因为每次添加“网络”节点时性能都会急剧下降
- CPU：这些数字是可重现的，我们在没有任何其他负载的虚拟机上进行了测试
- 慢速数据库查询：因为数字会根据我们是直接连接到集群节点之一还是使用本地主机而改变 - 可以排除
任何人都可以给我们指点，我们可以尝试什么或如何加速hyperv？还是我们搞砸了一些 galera/maxscale 设置？
编辑：我们检查了坏段并发现（netstat -s | grep 段）：
| 超级V | ESX | |
|---|---|---|
| 已收到 | 2448010940 | 2551382424 |
| 发送 | 5502198473 | 2576919172 |
| 重传 | 9054212 | 7070 |
| 坏段 | 83 | 0 |
| % 重传 | 0.16% | 0.00027% |
解决方案
多亏了 Mircea 的投入，我们终于在 hyperV 上获得了大幅下降的数字。
以下配置更改有帮助：
- 释放默认 Windows 绑定
- 激活 SET 团队
- 在 SET 团队上激活：RDMA 和巨型帧
有了这个，hyperV 上的数字基本上等同于 ESX
对于 VM，请确保安装准虚拟化驱动程序（Hyper-V 来宾集成和 VMWare 工具）。运行网络综合基准测试。监控路径上的所有设备（交换机、路由器、管理程序、虚拟机）的 CPU、网络计数器、中断、上下文切换......
在应用程序基准测试期间捕获流量。检查帧大小、TCP 窗口大小、TCP 流中丢弃的数据包、SYN、SYN/ACK、ACK TCP 握手之间的延迟，并与 SQL“ping”查询等应用程序延迟进行比较：SELECT 1 FROM DUAL; 在应用程序基准测试期间监控 CPU、网络、磁盘 I/O。
在虚拟机和裸机上运行基准测试。
其他一些文献：USE 方法（Utilization Saturation and Errors）和TSA 方法（线程状态分析）
监控工具会影响性能。检查它们的使用情况（CPU、网络和磁盘 I/O）。负载测试实用程序也在使用资源。确保正在进行负载测试的工作站未饱和。