Проблема с завершением %dopar% после создания экземпляра 'std::bad_alloc'

Я написал функцию, в которой я выполняю некоторый код параллельно:

 cl <- makeCluster(nc, outfile = "")
 registerDoParallel(cl, nc)

 pred <- foreach(s = iter(seq(1L,length(dfr_missings))),
                 .packages = c('RANN', 'randomForest','magrittr'),
                 .errorhandling = 'stop',
                 .verbose = F,
                 .combine = 'cbind',
                 .export = c("myRoughfix")) %dopar% {
                 #
                 #some code goes here
                 # 
                 }

stopCluster(cl)
stopImplicitCluster() 

Функция работает, как и ожидалось, с меньшими кадрами данных. Однако мне нужно, чтобы он работал с большими.

Я получаю следующую ошибку:

 Error in unserialize(socklist[[n]]) : error reading from connection
 terminate called after throwing an instance of 'std::bad_alloc'
   what():  std::bad_alloc

Насколько я понимаю сообщение об ошибке, оно указывает на то, что мне не хватило памяти. Размер кадра данных, с которым у меня возникают проблемы, составляет ~ 770 МБ. Я работаю на машине с 256 ГБ ОЗУ и 48 ядрами. Я ожидал, что эта машина сможет справиться с таким большим объектом. Код не делает ничего, что интенсивно использует память.

Итак, мой вопрос: возможно ли, что для рабочих процессов установлены некоторые ограничения памяти, которыми можно управлять с помощью глобальной опции? Возможно вариант ОС или makeCluster().

Любые другие мысли приветствуются.

P.S. Я нахожусь на предустановленной виртуальной машине на 64-битном oracle linux 6 с версией R - "Oracle Distribution of R version 3.1.1"


person deann    schedule 02.08.2017    source источник
comment
вы следили за процессом? Вы работаете над 64-битной версией R?   -  person loki    schedule 02.08.2017
comment
Кажется, это ошибка С++. Вы проверили это?   -  person loki    schedule 02.08.2017
comment
Я использую 64-битную версию R. Я видел, что это ошибка C++, однако я не уверен, как я могу попытаться обеспечить безопасное завершение программы, освободив неиспользуемые ресурсы в R. Вот почему я подумал, что может быть быть вариант для выделения памяти.   -  person deann    schedule 02.08.2017
comment
вы пробовали gc()?   -  person loki    schedule 02.08.2017
comment
что ты имеешь в виду?   -  person deann    schedule 02.08.2017
comment
Пробовали ли вы использовать сборщик мусора gc() в разделе вашего кода? Освобождает память, которая не используется. В моем коде я ставлю gc();gc();gc() после некоторых строк, особенно после огромных вычислений. Поскольку вы импортируете randomForest, я бы предположил, что сборка мусора может улучшить использование ресурсов.   -  person loki    schedule 02.08.2017
comment
Попробуйте следить за диспетчером задач, пока работает ваш код, и посмотрите, не достигаете ли вы предела памяти. Моя машина также имеет 256 ГБ ОЗУ, но при распараллеливании всего с 10 ядрами иногда может достигаться этот предел. Я считаю, что это потому, что все (включая пакеты и данные) передается каждому узлу. Вы также можете попробовать запустить меньше ядер, чтобы посмотреть, поможет ли это.   -  person BigTimeStats    schedule 02.08.2017
comment
Что это за функция: myRoughfix?   -  person nrussell    schedule 02.08.2017
comment
@nrussell, который представляет собой оболочку для randomForest::na.roughfix(). Он просто заранее подготавливает некоторые данные. В общем, #некоторый код здесь часть представляет собой последовательный код, который выполняет пользовательское вменение.   -  person deann    schedule 02.08.2017
comment
Вероятно, вам просто нужно запустить это через gdb, чтобы выяснить, в какой функции запускается неудачное выделение. Однако в нынешнем виде ваша проблема не воспроизводима.   -  person nrussell    schedule 02.08.2017
comment
Я удаляю тег Rcpp, поскольку здесь нет продемонстрированной связи с пакетом Rcpp.   -  person Dirk Eddelbuettel    schedule 02.08.2017
comment
Работает ли он с registerDoSEQ() (последовательно)?   -  person F. Privé    schedule 03.08.2017
comment
@DirkEddelbuettel Я использую пакет rcpp и получаю ту же необъяснимую ошибку.   -  person Parsa    schedule 04.04.2018