V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
MrLonely
V2EX  ›  问与答

有偿请教,明盘 50. ESXi 上的虚拟机卡顿如何解决?

  •  
  •   MrLonely · 2021-06-18 18:21:11 +08:00 · 2339 次点击
    这是一个创建于 1239 天前的主题,其中的信息可能已经有所发展或是发生改变。

    原始需求

    现在换了 M1 MacBook,还需要两个 X86 的 Win 10 系统来跑交易软件。其中一个 Win 10 系统对性能和流畅度要求不多。另外一个涉及到 API,Excel,Bloomberg 的运行,所以对性能要求比较高,使用也很频繁,所以对流畅度要求也高。

    当前设置

    经过我这段时间的折腾,现在一共有 3 个系统。

    系统 A:Window 10 LTSC,安装在 ESXi 里,分配了 8C 16G,宿主机为 PN51,Ryzen 7 5700U 64G RAM,访问方式为 VMRC 。已安装 VMware Tools 。Geekbench 分数为单核 1123,多核 5038.

    系统 B:Windows 10 LTSC,通过 Boot Camp 安装在 Mac mini 里。2018 款 Mac mini,i7-8700B+32G RAM,访问方式为 AnyDesk 。

    系统 C:Windows 10 21H1,香港 Azure,2C 8G,操作系统显示宿主机是 Xeon Platinum 8171M 2.6GHz,访问方式为 RDP 。Geekbench 分数为单核 700 多,多核 1300.

    问题描述

    系统 A 明显运行流畅度远低于合理期望。一个可横向对比的例子就是打开一个有 3 张 Sheet 的 Excel 文件,然后在三个 Sheet 之间来回切换,系统响应速度明显低于另外两个系统。花费时常最少为 3 倍于对比系统。

    并且在做上述对比的同时没有任何其他的大型软件正在运行。也没有装过任何流氓软件。

    尝试解决

    我试着网上搜索了“ESXi 卡顿”关键词。根据网上内容,增加了 VM 的 3D Video Memory 到 2G,打开了 CPU 选项里的 IOMMU,Hardware virtualization,Performance counters,依然没有任何缓解。

    疑惑

    那么现在问题是,说这是资源不够吧?但其实我分配的资源多核跑出来的成绩已经明显高于单纯一个 Excel 能够消耗的资源了。更何况我运行几个大型程序的时候,任务管理器显示的 CPU 和 RAM 也就 50%左右,没有到资源捉襟见肘的地步。但是大型程序都跑起来会显著加剧卡顿。

    要说是虚拟机转换效率差吧?那 Azure 也是个 VM,给的资源还比我自己给的小气得多。可是它在只运行 Excel 的时候能做到跟系统 B 一样的流畅度。

    要说是虚拟显卡资源不够的话,那也没理由 Azure 能给 2G 以上的 3D Video Memory 啊。

    所以这问题到底是出在哪里呢?

    如果有朋友知道解决方法但是需要进行专业的技术支持也可以加钱。价格再议。

    一点题外话

    我对于显示效果和使用方便,运行速度都有要求。现在来说 A 和 B 两个方案已经是最优秀的两个方案了。如果虚拟机卡顿没办法解决但是大家有对我的 Setup 有所建议的采用以后也会付费。

    系统 A 除了卡顿没有缺点了。

    系统 B 用 AnyDesk 的话流畅度基本满意,但是屏幕偶尔会有图像压缩的痕迹。还有就是 AnyDesk 在传输键盘的时候是直接传输字符的。也就是我在 MacBook 上忘记把输入法换成英文的情况下在 Win 里面输入账号密码什么的是显示不出来的。不用 RDP 是因为 RDP 连接下无法修改 Windows 为 150%的 Zoom,我用的是 32 寸 4K 显示器,100%着实是有点小了。还有一个 RDP 和 AnyDesk 共同的问题是 Command+C 无法复制,要用 Ctrl 。

    但是 VMRC 不存在以上系统 B 的缺点。还可以做 USB 重定向。

    系统 C 2C 8G 只运行 Excel 可以,但是上面说的 API+Excel+Bloomberg 全部放上去肯定也够呛。而且也舍不得在 Azure 买更贵的机器了,再加配置就超额度了。而且也存在 RDP 无法修改 Zoom 的问题,

    求各位老哥帮忙。

    12 条回复    2021-06-22 18:35:49 +08:00
    bitdepth
        1
    bitdepth  
       2021-06-18 18:40:42 +08:00 via iPad
    這比較毫無意義,Anydesk 橫向比較才有價值
    zvcs
        2
    zvcs  
       2021-06-18 18:50:54 +08:00 via iPhone
    系统 A 放到 ssd 里看看
    MrLonely
        3
    MrLonely  
    OP
       2021-06-19 00:43:19 +08:00
    @bitdepth 我刚给系统 A 也装了 AnyDesk,还是一样的卡。

    @zvcs 本来就是在 NVMe 的 SSD 里的,VMDK 也是 NVMe 协议的。不过你这么说我就去测了个速。

    https://imgur.com/PpHmEIE

    这数据看起来正常吗?
    MrLonely
        4
    MrLonely  
    OP
       2021-06-19 00:44:07 +08:00
    [img][/img]
    zvcs
        5
    zvcs  
       2021-06-19 07:16:47 +08:00 via iPhone
    数据很正常。你看看图形设置,能直通一张显卡吗?
    bitdepth
        6
    bitdepth  
       2021-06-19 10:39:53 +08:00 via iPad
    原本猜測可能是 GPU 加速的問題,但是沒有道理效果會比 C 更好,而且都用了 Anydesk
    MrLonely
        7
    MrLonely  
    OP
       2021-06-19 12:37:31 +08:00
    @zvcs PN51 是一个华硕做的 AMD 版 NUC,没有独立 GPU,我在直通列表里面也没看到核显可以被直通。
    https://imgur.com/wBnplSL.jpg
    MrLonely
        8
    MrLonely  
    OP
       2021-06-19 12:38:30 +08:00
    ccde8259
        9
    ccde8259  
       2021-06-20 18:39:54 +08:00 via iPhone
    R7 5700U 全锅?
    Intel 大胜利!
    MrLonely
        10
    MrLonely  
    OP
       2021-06-22 08:57:24 +08:00
    @ccde8259 好像真的是 AMD 的锅
    后续情况是我给 Mac mini 也装了 ESXi,把系统 A Clone 到 Mac mini 上之后打开运行并没有明显卡顿。
    我还在 PN51 上面直接装了 Windows,运行之后也没有明显卡顿。
    所以目前来看,似乎是 AMD+ESXi 水土不服。

    但是不知道这是为什么。
    MrLonely
        11
    MrLonely  
    OP
       2021-06-22 08:58:40 +08:00
    @ccde8259 虽然并没有帮我直接解决问题,但是起码帮我正确定位了问题,私信我一下你的 zfb 收款方式吧。我给你转钱。
    ccde8259
        12
    ccde8259  
       2021-06-22 18:35:49 +08:00 via iPhone
    @MrLonely 老铁,别,我这只是随便开的地图炮。没能真正解决问题,这钱不敢要。
    AMD 的 SVM 默认是关闭的,开启 SVM 外频会掉到 98.6MHz 左右。种种迹象让我觉得他可能有坑而已。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1030 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 19:17 · PVG 03:17 · LAX 11:17 · JFK 14:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.