Насколько я понял,
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, поскольку он резервирует только доступное пространство, а если свободного места нет, это не имеет значения?
Хорошо, я нашел ответ на это, проверив /proc/<pid>/limits запущенного процесса задания на сервере выполнения.
Когда я отправляю работу с h_rss=10G, в пределах значения Max Resident Set установлено 10737418240 байт (т. е. 10G). (Значение по умолчанию в ОС не ограничено) Таким образом, процесс не может занимать больше памяти. А также h_rss это то, что не расходный материал.
А когда я отправляю вакансию с h_vmem=50G, в пределах значения Max Resident Set равно неограниченный. Итак, это может продолжаться и дальше 50 г. Однако это расходный материал и, следовательно, h_vmem хоста уменьшается на 50 г.
Это можно узнать, выполнив следующие команды:
qhost -h <hostname> -F h_vmem, где h_vmem показывает текущее значение h_vmem, а qconf -se <hostname>, где h_vmem в complex_values показывает выделенное значение h_vmem.Можно настроить, является ли ресурс потребляемым или нет, и сколько может быть зарезервировано в системе. Вы можете использовать одно из существующих значений или создать новое на ваше усмотрение.
Хотя в любом случае это не повредит, 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, которые никогда не отражаются как физическая память, чтобы уменьшить фрагментацию памяти. Каждая хромированная вкладка на моем ноутбуке объемом 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. Последнее позволяет контрольной группе превысить свои резервы, пока системе не не хватает памяти. Это улучшает способность ядра кэшировать файлы от имени этих процессов, повышая производительность для всех, но есть риск того, что, когда системе действительно не хватает памяти, возникают обстоятельства, при которых убийца OOM не успевает осмотреться. для процесса, который нужно убить из контрольной группы с превышением лимита, и вместо этого попытка выделения памяти завершится неудачно.