Я использую Vagrant на MacOS с ubuntu64 16.04. Запуск htop, я вижу, vagrant ssh процесс может использовать практически 530G (в VIRT Столбец).Htop говорит «530G» в «VIRT» для «vagrant ssh»
Это обычное поведение бродяг? Должен ли я паниковать? «Нормально» иметь практически 530G на Mac с 120G диском и 16G RAM? Или, может быть, я не понял смысл VIRT?
Бродячий бокс работает на виртуальной коробке и имеет только 1 ГБ ОЗУ.
Ответа на этот вопрос chrisroberts на github:
Привет! Я смог воспроизвести это поведение, но с любой казенной командой. Команда vagrant ssh проще всего видеть это поведение просто потому, что процесс остается включенным до тех пор, пока сеанс ssh жив.
Версия ниже приведена ниже: просто не беспокойтесь об этом. VIRT не выделяется память. Если бы это было так, вам понадобилось бы огромное пространство подкачки, или ничего не получилось бы.
Итак, что здесь происходит? Бродячий установщик включает в себя небольшой исполняемый файл (бродяга), задачей которого является настройка текущей среды с надлежащим расположением всего, что ему нужно. Каталог bin инсталляторов, каталог lib для ruby и всех других друзей, все драгоценные камни и сам бродячий камень. После того, как все это настроено, оно генерирует новый процесс, фактический бродячий процесс Ruby.
Поскольку ваш пример ссылался на бродячий ssh, и, как указывалось ранее (#7296 (comment)), Kernel.exec происходит, поскольку процесс Ruby не сохраняется, я полагал, что это должна быть оболочка, которая была виновником. После недолгого поиска (в основном, чтобы найти StackOverflow пунктов говоря «не беспокоиться о ВИРТ») я наткнулся на:
Они относятся к golang FAQ, что переговоры о связке ВИРТ заявляемого вверх фронт, и это не большое дело, но никогда не было абсолютов о том, сколько на самом деле было заявлено. Ссылка на lwn была отброшена там (keybase/keybase-issues#1908 (comment)) относительно поведения голанга при запуске, требуя огромного куска VIRT, но все же все ссылалось на гораздо меньшую сумму, чем я видел на местном уровне. Поэтому я решил пойти копаться в коде выполнения golang, и в malloc.go мы находим ответ:
почему это происходит из-за ходу обертки используется для запуска бродягу. Потому что VIRT, который вы видите, - это просто резервирование, а не фактическое выделение, это не проблема, а не то, о чем нужно беспокоиться.
(Есть несколько интересных разговоров о golang ML вокруг плюсов и минусов этого подхода, все довольно красивые чтения).
Это всего лишь копия/вставка (и выделена жирным шрифтом), надеюсь, что это может помочь кому-то еще.