我在带有 ubuntu64 16.04 的 MacOS 上使用 Vagrant。运行htop，可以看到vagrant ssh进程几乎可以使用530G（在VIRT列中）。
这是 Vagrant 的正常行为吗？我应该恐慌吗？在具有 120G 磁盘和 16G RAM 的 Mac 上几乎有 530G 是否“正常”？还是我没看懂VIRT的意思？
vagrant box 在 virtual box 上运行，只分配了 1G 的 RAM。
【问题讨论】：
标签： macos memory vagrant virtualbox htop
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”的 stackoverflow 项目），我偶然发现：
他们参考了 golang 常见问题解答，其中谈到了预先声明了一堆 VIRT，这没什么大不了的，但从来没有关于实际声明了多少的绝对值。一个指向 lwn 的链接被丢弃在那里 (keybase/keybase-issues#1908 (comment)) 关于 golang 在启动时声称大量 VIRT 的行为，但仍然所有引用的数量都比我在本地看到的要低得多。所以我决定深入研究 golang 运行时代码，并在 malloc.go 中找到答案：
发生这种情况的原因是用于启动 vagrant 的 go 包装器。因为您看到的 VIRT 只是一个预留，并没有实际分配，所以这不是问题，也不应该担心。
（关于这种方法的优缺点，关于 golang ML 有一些有趣的对话，都非常棒）。
这只是一个复制/粘贴（并加粗了 TLDR），希望它可以帮助其他人。
【讨论】：