Htop 在“VIRT”中为“vagrant ssh”说“530G”

Posted 2023-04-14

【中文标题】Htop 在“VIRT”中为“vagrant ssh”说“530G”

【英文标题】：Htop says "530G" in "VIRT" for "vagrant ssh"

【发布时间】：2017-02-13 23:33:00

【问题描述】：

我在带有 ubuntu64 16.04 的 MacOS 上使用 Vagrant。运行htop，可以看到vagrant ssh进程几乎可以使用530G（在VIRT列中）。

这是 Vagrant 的正常行为吗？我应该恐慌吗？在具有 120G 磁盘和 16G RAM 的 Mac 上几乎有 530G 是否“正常”？还是我没看懂VIRT的意思？

vagrant box 在 vi​​rtual box 上运行，只分配了 1G 的 RAM。

【参考方案1】：

chrisroberts 在github 上回答：

嗨！我能够重现这种行为，但是执行了任何 vagrant 命令。 vagrant ssh 命令最容易看到这种行为，因为只要 ssh 会话处于活动状态，进程就会一直运行。

下面的 tl;dr 版本很简单：别担心。 VIRT 没有分配内存。如果是这样，您要么需要大量的交换空间，要么什么都不会工作。

那么，这里发生了什么？ vagrant 安装程序包含一个小型 go 可执行文件 (vagrant)，其工作是设置当前环境及其所需所有内容的正确位置。安装程序的 bin 目录、ruby 和所有其他朋友的 lib 目录、所有 gem 和 vagrant gem 本身。配置完所有这些后，它会生成一个新进程，即实际的 Ruby vagrant 进程。

因为您的示例引用了 vagrant ssh，并且正如之前指出的 (#7296 (comment)) 发生了 Kernel.exec，这意味着 Ruby 进程不会持续存在，所以我认为它一定是罪魁祸首的包装器。经过一番搜索（主要是为了找到说“不要担心 VIRT”的 *** 项目），我偶然发现：

keybase/keybase-issues#1908

他们参考了 golang 常见问题解答，其中谈到了预先声明了一堆 VIRT，这没什么大不了的，但从来没有关于实际声明了多少的绝对值。一个指向 lwn 的链接被丢弃在那里 (keybase/keybase-issues#1908 (comment)) 关于 golang 在启动时声称大量 VIRT 的行为，但仍然所有引用的数量都比我在本地看到的要低得多。所以我决定深入研究 golang 运行时代码，并在 malloc.go 中找到答案：

golang src/runtime/malloc.go

发生这种情况的原因是用于启动 vagrant 的 go 包装器。因为您看到的 VIRT 只是一个预留，并没有实际分配，所以这不是问题，也不应该担心。

（关于这种方法的优缺点，关于 golang ML 有一些有趣的对话，都非常棒）。

这只是一个复制/粘贴（并加粗了 TLDR），希望它可以帮助其他人。