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