Предотвратить использование 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 об этом.)

Это может быть эффективный способ предотвращения ситуаций перебоев. Но компромисс заключается в том, что вы теряете преимущество, которое превзойдёт, когда вещи хорошо себя ведут (переполняют все больше процессов в память).