Htop 在 "VIRT" 中为 "vagrant ssh" 说“530G”
Htop says "530G" in "VIRT" for "vagrant ssh"
我在带有 ubuntu64 16.04 的 MacOS 上使用 Vagrant。 运行 htop，我可以看到 vagrant ssh 进程实际上可以使用 530G（在 VIRT 列中）。
这是Vagrant的正常行为吗？我应该恐慌吗？在具有 120G 磁盘和 16G RAM 的 mac 上实际上有 530G 是 "normal" 吗？还是我没看懂VIRT的意思？
vagrant box运行在virtual box上，只分配了1G内存。
回答者chrisroberts on github：
Hi! I was able to reproduce this behavior, but with any vagrant command executed. The vagrant ssh command is the easiest to see this behavior simply because the process is left running for as long as the ssh session is alive.
The tl;dr version of below is simply: Don't worry about it. VIRT isn't allocated memory. If it were, you would either need massive swap space, or nothing would be working.
So, what's going on here? The vagrant installer includes a small go executable (vagrant) whose job is to setup the current environment with the proper locations of everything it needs. The installers bin directory, the lib directory for ruby and all the other friends, all the gems, and the vagrant gem itself. Once it has all this configured, it spawns off a new process, the actual Ruby vagrant process.
Because your example was referencing vagrant ssh, and as was previously pointed out (#7296 (comment)) a Kernel.exec happens meaning the Ruby process does not persist, I figured it must be the wrapper that was the culprit. After a bit of searching (mostly to find Whosebug items saying "don't worry about VIRT") I stumbled upon:
They refer to the golang FAQ that talks about a bunch of VIRT being claimed up front and it not being a big deal, but never any absolutes about how much was actually being claimed. A link to lwn was dropped in there (keybase/keybase-issues#1908 (comment)) regarding golang's behavior on startup of claiming a huge chunk of VIRT, but still everything referenced a much lower amount than I was seeing locally. So I decided to go dig into the golang runtime code, and within malloc.go we find the answer:
The why it's happening is because of the go wrapper used to start vagrant. Because the VIRT you see is simply a reservation and not actually allocated, it's not a problem and not something that should be worried about.
(There are some interesting conversations on the golang ML around the pros and cons of this approach, all pretty great reads).
这只是一个 copy/paste（并加粗了 TLDR），希望它能帮助其他人。
我在带有 ubuntu64 16.04 的 MacOS 上使用 Vagrant。 运行 htop，我可以看到 vagrant ssh 进程实际上可以使用 530G（在 VIRT 列中）。
这是Vagrant的正常行为吗？我应该恐慌吗？在具有 120G 磁盘和 16G RAM 的 mac 上实际上有 530G 是 "normal" 吗？还是我没看懂VIRT的意思？
vagrant box运行在virtual box上，只分配了1G内存。
回答者chrisroberts on github：
Hi! I was able to reproduce this behavior, but with any vagrant command executed. The vagrant ssh command is the easiest to see this behavior simply because the process is left running for as long as the ssh session is alive.
The tl;dr version of below is simply: Don't worry about it. VIRT isn't allocated memory. If it were, you would either need massive swap space, or nothing would be working.
So, what's going on here? The vagrant installer includes a small go executable (vagrant) whose job is to setup the current environment with the proper locations of everything it needs. The installers bin directory, the lib directory for ruby and all the other friends, all the gems, and the vagrant gem itself. Once it has all this configured, it spawns off a new process, the actual Ruby vagrant process.
Because your example was referencing vagrant ssh, and as was previously pointed out (#7296 (comment)) a Kernel.exec happens meaning the Ruby process does not persist, I figured it must be the wrapper that was the culprit. After a bit of searching (mostly to find Whosebug items saying "don't worry about VIRT") I stumbled upon:
They refer to the golang FAQ that talks about a bunch of VIRT being claimed up front and it not being a big deal, but never any absolutes about how much was actually being claimed. A link to lwn was dropped in there (keybase/keybase-issues#1908 (comment)) regarding golang's behavior on startup of claiming a huge chunk of VIRT, but still everything referenced a much lower amount than I was seeing locally. So I decided to go dig into the golang runtime code, and within malloc.go we find the answer:
The why it's happening is because of the go wrapper used to start vagrant. Because the VIRT you see is simply a reservation and not actually allocated, it's not a problem and not something that should be worried about.
(There are some interesting conversations on the golang ML around the pros and cons of this approach, all pretty great reads).
这只是一个 copy/paste（并加粗了 TLDR），希望它能帮助其他人。