我在带有 ubuntu64 16.04 的 MacOS 上使用 Vagrant。运行htop，我可以看到vagrant ssh进程几乎可以使用 530G（在VIRTColumn 中）。
这是Vagrant的正常行为吗？我应该恐慌吗？在具有 120G 磁盘和 16G RAM 的 Mac 上几乎有 530G 是否“正常”？或者也许我没有理解 的含义VIRT？
vagrant box 在 virtual box 上运行，只分配了 1G 的 RAM。
问问题
1223 次
1 回答
0
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 进程不会持续存在，所以我认为它一定是罪魁祸首的包装器。经过一番搜索（主要是为了找到 stackoverflow 项目说“不要担心 VIRT”），我偶然发现：
他们参考了 golang 常见问题解答，其中谈到了预先声明了一堆 VIRT，这并不是什么大不了的事，但从来没有关于实际声明了多少的绝对值。关于 golang 在启动时声称拥有大量 VIRT 的行为，在那里删除了一个指向 lwn 的链接（keybase/keybase-issues#1908（评论）），但仍然所有引用的数量都比我在本地看到的要低得多。所以我决定深入研究 golang 运行时代码，并在 malloc.go 中找到答案：
发生这种情况的原因是用于启动 vagrant 的 go 包装器。因为您看到的 VIRT 只是一个预留，并没有实际分配，所以这不是问题，也不应该担心。
（关于这种方法的优缺点，golang ML 上有一些有趣的对话，都非常棒）。
这只是一个复制/粘贴（并加粗了 TLDR），希望它可以帮助其他人。
于 2016-10-09T12:14:20.937 回答