Изучите программное обеспечение пакетной очереди, такое как TORQUE , PBS , Slurm и т. Д. Оно позволяет вам создать очередь, в которой пользователи отправляют свои задачи, и программа запускается что на имеющихся машинах. Обратите внимание, что этот подход хорошо работает только с неинтерактивными материалами.
Параметры vm.overcommit _ *
управляют распределением памяти в пользовательском пространстве. Они не влияют на память, которую может выделить ядро.
Кроме того, вы берете 50% от физической памяти + подкачки. 47 + 47 = 94. Таким образом, пользовательское пространство может занимать до 47 ГБ.
Ваш бесплатный вывод
показывает, что у вас есть 1 ГБ, используемое пользовательским пространством, и 45 ГБ, используемое ядром для кеширования. 1 ГБ пользовательского пространства - это меньше 50% от 94 ГБ.
Дополнительное исправление:
vm.overcommit_memory = 2
не позволит переопределить память, превышающую 50% ОЗУ
Этот параметр вообще не позволит переопределить . В сочетании с vm.overcommit_ratio = 50
это позволит пользовательскому пространству выделять до 50% общей памяти. "commit"! = "overcommit"
На самом деле, установка vm.overcommit _memory=2 ДЕЙСТВИТЕЛЬНО допускает перегрузку. Если вы установите коэффициент чрезмерной фиксации _равным (, скажем, )200, тогда память может быть выделена в размере swap + (RAM *200/100 ).
Документация ядра немного вводит в заблуждение, подразумевая, что '2' означает не перегружать -, это означает фиксацию до этого предела, который в случае превышения _коэффициента (и это неправильное название, так как на самом деле процент ), превышающий 100, допускает чрезмерную фиксацию.
vm.overcommit _память более точно описывается как установка предела для избыточного выделения, которое по умолчанию не допускает избыточного выделения.
Вы можете увидеть лимит фиксации:
$free -m | awk '$1 ~/[Mm]em/ {print $2}' ; sysctl -a 2>/dev/null | grep vm.over ; grep -i commitlimit /proc/meminfo
vm.overcommit_kbytes = 0
vm.overcommit_memory = 2
vm.overcommit_ratio = 800
CommitLimit: 23449596 kB