我在带有ubuntu64 16.04的MacOS上使用Vagrant。运行htop，我可以看到vagrant ssh进程可以使用虚拟530G（在VIRT列中）。
这是Vagrant的正常行为吗？我应该恐慌吗？是＃＆＃34;正常＆＃34;在拥有120G磁盘和16G内存的Mac上实际拥有530G？或者我可能不理解VIRT的含义？
vagrant box在虚拟盒子上运行，只分配了1G的RAM。
答案 0 :(得分：0)
chrisroberts在github上回答：
嗨！我能够重现这种行为，但执行了任何vagrant命令。 vagrant ssh命令最容易看到这种行为，因为只要ssh会话处于活动状态，进程就会一直运行。
下面的tl; dr版本就是：不要担心。 VIRT没有分配内存。如果是的话，你可能需要大量的交换空间，或者没有任何工作。
那么，这里发生了什么？ vagrant安装程序包括一个小的可执行文件（vagrant），其工作是使用所需的一切的适当位置设置当前环境。安装程序bin目录，ruby的lib目录和所有其他朋友，所有gem，以及vagrant gem本身。一旦完成所有这些配置，它就会产生一个新进程，即实际的Ruby vagrant进程。
因为你的例子引用了vagrant ssh，并且正如之前所指出的那样（#7296 (comment)），一个Kernel.exec发生意味着Ruby进程不会持久存在，我认为它必须是包装器的罪魁祸首。经过一些搜索（主要是为了找到堆栈溢出项目说“不要担心VIRT”）我偶然发现：
他们参考了Golang常见问题解答，该常见问题谈论了一堆预先声称的VIRT，这并不是什么大问题，但从来没有任何关于实际声称的数量的绝对值。关于llang的链接被放在那里（keybase/keybase-issues#1908 (comment)）关于golang在声称大量VIRT的启动时的行为，但是仍然所有引用的数量远低于我在本地看到的数量。所以我决定深入研究golang运行时代码，在malloc.go中我们找到答案：
它发生的原因是因为用于启动流浪汉的go包装器。因为您看到的VIRT只是一个保留而不是实际分配，所以这不是问题，也不应该担心。
（golang ML上有一些有趣的对话，围绕这种方法的优点和缺点，所有读取都很棒。）
它只是一个复制/粘贴（并用TLDR加粗），希望它可以帮助别人。