В чем разница между h_rss и h_vmem в Sun Grid Engine (SGE)?
Насколько я понял,
mem_freeможно указать, чтобы отправить работу на хост, который имеет свободную память =mem_free, в то время какh_vmemявляется жестким пределом памяти, до которой работа может потребляться, и если работа достигаетh_vmemработа падает? Я думаю, что мы можем установитьh_vmemхоста рядом с общей физической памятью, чтобы задание не начиналось с подкачки и не замедляло работу сервера.
Тогда что h_rss? Кажется, имеет то же определение, что и h_vmem.
Или я неправильно понимаю h_vmem? Является h_vmem используется для резервирования дополнительной памяти, которая может потребоваться, чем минимальная необходимая память (mem_free)? Но не сбой, если он превышает память, поэтому работа может превысить h_vmem?
Если моя вторая интерпретация h_vmem Правильно, тогда я предполагаю, что для задания, которое будет отправлено на хост, задание должно удовлетворять mem_free а также h_vmem (дано h_vmem это не бесконечность).
И если моя первая интерпретация h_vmem Правильно, то, я думаю, для работы, которая будет представлена на хосте, работа может удовлетворить mem_free один и не нужно удовлетворять h_vmem, поскольку он только резервирует доступное пространство, и если свободного места нет, это не имеет значения?
2 ответа
Является ли ресурс потребляемым или нет, и сколько можно зарезервировать в системе, можно настраивать. Вы можете использовать одно из существующих значений или создать новое, до вас.
Хотя в любом случае нет ничего плохого в его настройке, mem_free по умолчанию не расходуется. Это означает, что, хотя при запуске задания в системе должен быть доступный объем памяти, все 10 заданий, для каждого из которых требуется 10 ГБ свободной памяти, могут одновременно запускаться на сервере с 11 ГБ свободной памяти. Если все они на самом деле используют 10 ГБ, у вас будут проблемы.
Различия между остальными сводятся к принуждению. rss (использование физической памяти) не применяется. vmem (использование виртуальной памяти) есть. К сожалению, linux не предлагает хороших способов принудительного использования физической памяти (cgroups в порядке, но rss ulimit на самом деле ничего не делает в современных ядрах).
С другой стороны, очень важно признать, что НЕТ правильного способа рассматривать vmem как расходный ресурс. Если вы компилируете "Hello World" в C с -fsanitize=address опция отладки (доступно в clang или gcc5+), она будет использовать 20 ТБ виртуальной памяти, но менее 5 МБ физической памяти. Среды сбора мусора, такие как Java и Go, также выделяют значительное количество vmem, которое никогда не отражается как физическая память, чтобы уменьшить фрагментацию памяти. Каждая вкладка Chrome на моем 8-Гбайт ноутбуке использует 2 ТБ виртуальной памяти как часть своей изолированной среды безопасности. Все это вполне разумно для программ, и установка нижнего предела не позволяет работать программам с хорошим поведением. Также очевидно, что установка ограничения расхода vmem 20 ТБ в системе не имеет смысла.
Если по какой-либо причине вы должны использовать h_vmem, разница между h_ а также s_ варианты - какой сигнал используется для уничтожения процессов, которые превышают предел - h_ убивает процессы с SIGKILL (например, kill -9), в то время как s_ использует сигнал, который может обрабатывать процесс (позволяющий корректно завершить работу с хорошим поведением или плохо вести себя, чтобы проигнорировать сигнал). Лучший совет - сначала плакать, потому что ограничения vmem изначально нарушены, а затем установите h_vmem немного выше, чем s_vmem, чтобы задания могли умереть с полезным сообщением об ошибке.
Я бы посоветовал администратору кластера настроить h_rss на использование, установить h_rss и mem_free в шаблоне работы, вообще избегать h_vmem и надеяться, что люди не злоупотребляют системой из-за недостаточного резервирования памяти. Если требуется механизм принудительного применения, он сложен, но можно настроить диспетчер заданий так, чтобы он помещал задания в группы памяти и устанавливал либо memory.limit_in_bytes, либо memory.soft_limit_in_bytes. Последнее позволяет cgroup превышать свое резервирование, если системе не хватает памяти. Это улучшает способность ядра кешировать файлы от имени этих процессов, повышая производительность для всех, но существует риск того, что, когда системе действительно не хватает памяти, существуют обстоятельства, при которых убийца OOM не имеет времени просматривать. для процесса, который нужно уничтожить из чрезмерно ограниченной группы, и вместо этого попытка выделения потерпит неудачу.
Хорошо, я нашел ответ на этот вопрос, проверив /proc/<pid>/limits запущенного процесса задания на исполнительном сервере.
Когда я отправляю работу с
h_rss=10Gв пределах стоимостиMax Resident Setустанавливается на 10737418240 байт (т. е. 10G). (Значение по умолчанию в ОС не ограничено). Таким образом, процесс не может взять память за пределы этого. А такжеh_rssэто то, что не расходуется.Принимая во внимание, что, когда я отправляю работу с
h_vmem=50Gв пределах стоимостиMax Resident Setравно неограниченному. Таким образом, это может продолжаться за 50G. Тем не менее, это расходный материал и, следовательно,h_vmemхоста уменьшается на 50г.Это можно узнать, выполнив следующие команды:
qhost -h <hostname> -F h_vmemгде h_vmem показывает текущее значение h_vmem иqconf -se <hostname>где h_vmem в complex_values показывает выделенное значение h_vmem.