как контролировать потенциальную вилочную бомбу, вызванную Маклаппли, попробовал ulimit, но не сработало

#r #parallel-processing #fork #core #mclapply

Вопрос:

Я использую mclapply в своем R-скрипте для параллельных вычислений. Это экономит общее использование памяти и работает быстро, поэтому я хочу сохранить его в своем сценарии. Однако я заметил одну вещь: количество дочерних процессов, созданных во время выполнения сценария, превышает количество ядер, которые я указал при использовании mc.cores . В частности, я запускаю свой скрипт на сервере со 128 ядрами. И когда я запускаю свой сценарий, я устанавливаю mc.cores значение 18. Во время выполнения скрипта я проверил процессы, связанные с использованием моего скрипта htop . Во-первых, я могу найти 18 процессов, подобных этому: введите описание изображения здесь

3_га_оптимизация.R-это мой сценарий. Все это выглядит хорошо. Но я также обнаружил, что более 100 процессов выполняются одновременно с аналогичной памятью и использованием процессора. На скриншоте ниже показаны некоторые из них: введите описание изображения здесь

Проблема в том, что, хотя мне требовалось всего 18 ядер, сценарий фактически использует все 128 ядер на сервере, и это делает сервер очень медленным. Итак, мой первый вопрос: почему это происходит? И в чем разница между этими процессами с зеленым цветом по сравнению с 18 процессами с черным цветом?

Мой второй вопрос заключается ulimit -Su 100 в том, что я пытался установить мягкий предел максимального количества процессов, которые я могу использовать перед запуском Rscript 3_GA_optimization.R . Я выбрал 100, основываясь на текущем количестве процессов, которые я использую перед запуском сценария, и количестве ядер, которые я хочу использовать при запуске сценария. Однако я получил сообщение об ошибке:

Ошибка в mcfork(): не удалось выполнить вилку, возможная причина: Ресурс временно недоступен

Таким образом, кажется, что mclapply для запуска скрипта требуется генерировать намного больше процессов, чем mc.cores для того, чтобы он запускался, что меня сбивает с толку. Итак, мой второй вопрос заключается в том, почему mclapply он ведет себя таким образом? Есть ли какой-либо другой способ исправить общее количество ядер mclapply , которые можно использовать?

Комментарии:

1. Я сомневаюсь parallel::mclapply() , что здесь есть в чем винить. Вместо этого я подозреваю, что вы испытываете вложенный параллелизм, то есть распараллеливаете что-то, что, в свою очередь, работает параллельно внутри.

2. Спасибо вам за это предложение. Я думаю, что вы правы. Я использовал ranger для классификации случайных лесов внутри mclapply . По умолчанию ranger использует все доступные процессоры. Таким образом, именно этот шаг генерирует больше процессов и занимает все ядра. Это мой первый пост здесь, так как я могу отметить ваш ответ как ответ?

3. Хорошо, что ты это понял. Я не думаю, что вы можете отметить комментарий как ответ, поэтому я опубликовал «ответ» с кратким изложением.

Ответ №1:

OP продолжил в комментарии 2021-05-17 и подтвердил, что проблема заключалась в их распараллеливании с помощью mclapply() вызываемых функций пакета ranger, которые, в свою очередь, распараллеливались с использованием всех доступных ядер процессора. Этот вложенный параллелизм приводит к тому, что R использует гораздо больше ядер процессора, чем доступно на компьютере.