vir东京的稳定性

你的头番号多少

就一张图片 没别的

这绝对不是我们有信心的事情，这是我们的一个大问题。我已经监控了碰撞，这似乎不是问题。

一切都表明它是另一回事。

例如，TYOC026 更专门地填充了最有可能不用于 扶墙 的大型服务，它现在的数据包数量要少得多，而且与使用相同主板、NIC 和相同交换机的其他节点相比，它的网络更顺畅。同一个 VLAN。

TYOC033 是用于 扶墙 的这些较小的 384MB 数据包数量最多的节点，数据包数量是其 3 倍。它上面的网络看起来也不错。

TYOC029 看起来是目前最差的一个，它实际上比 TYOC033 具有更低的 CPU 使用率和更少的虚拟机数量，并且在位输入/输出方面也具有更低的总网络使用率，但峰值高达 6 倍数据包TYOC026 的数量并保持高出 3 倍的基线。在这一点上，NIC 努力跟上，我们需要进行修改以改进它。我知道我们可以做些什么来修复它，问题是 SolusVM 不支持它。我们需要的可能多年来一直在功能请求中，所以我需要尝试寻找其他解决方案。我们现在已经足够稳定了，以后我想探索使用多个端口并在它们之间进行平衡，因为它确实有另一个可用的 NIC，我只需要做更多的研究，看看这是否真的有帮助，或者聚合它们是否会只是添加更多问题。

我确实有一个在网络方面更专业的人来看看，他或多或少地同意了。当然，我对所有更具体的建议持开放态度，因为我的时间仍然非常有限。

我并不是说不存在 VLAN 问题，我们会忘记它，但对于目前这个特定问题，这并不是影响它的主要因素。