Предотвратить использование R из виртуальной памяти в unix/linux?
Краткая версия
Есть ли способ предотвратить использование R из любой виртуальной памяти на Unix-машине? Всякий раз, когда это происходит, это происходит из-за того, что я прищурился, и тогда я хочу прекратить вычисление.
Более длинная версия
Я работаю с большими наборами данных на мощном компьютере, совместно используемом несколькими другими людьми. Иногда я запускаю команды, для которых требуется больше оперативной памяти, чем доступно, что заставляет R начинать замену и, в конечном итоге, замораживать всю машину. Обычно я могу решить это, установив ulimit в мой ~/.bashrc
ulimit -m 33554432 -v 33554432 # 32 GB RAM of the total 64 GB
который заставляет R выкидывать ошибку и прерывать при попытке выделить больше памяти, чем доступно. Однако, если я ошибаюсь в этом роде при распараллеливании (обычно с использованием пакета snow), ulimit не имеет никакого эффекта, и машина все равно сработает. Я думаю, это потому, что snow запускает рабочих как отдельные процессы, которые не запускаются в bash. Если я вместо этого попытаюсь установить ulimit в моем ~/.Rprofile, я просто получаю сообщение об ошибке:
> system("ulimit -m 33554432 -v 33554432")
ulimit: 1: too many arguments
Может ли кто-нибудь помочь мне выяснить способ сделать это?
Боковая дорожка
Почему я не могу установить ulimit из 0 виртуальной памяти в bash?
$ ulimit -m 33554432 -v 0
Если я это сделаю, он быстро выключится.
Ответы
Ответ 1
При запуске system("ulimit"), который выполняется в дочернем процессе. Родитель не наследует ulimit от родителя. (Это похоже на выполнение system("cd dir"), или system("export ENV_VAR=foo").
Установка его в оболочку, из которой вы запускаете среду, является правильным способом. Предел не работает в параллельном случае, скорее всего, потому что это предел для каждого процесса, а не глобальный системный предел.
В Linux вы можете настроить строгую (er) учетную запись overcommit, которая пытается помешать ядру обработать запрос mmap, который не может быть сохранен физической памятью.
Это делается путем настройки параметров sysctl vm.overcommit_memory и vm.overcommit_ratio. (Google об этом.)
Это может быть эффективный способ предотвращения ситуаций перебоев. Но компромисс заключается в том, что вы теряете преимущество, которое превзойдёт, когда вещи хорошо себя ведут (переполняют все больше процессов в память).
