2015-10-16 3 views
1

Я запускаю довольно простую искру, которая читает во многих файлах s3 один за другим и вызывает задание карты/фильтра на RDD и записывает результаты в другой s3. Другими словами, в каждом цикле есть первый цикл for, есть один sc-вызов для чтения, обработки, а затем записи шагов.GC замедляет работу искры до остановки

Шаги ненормально медленны, хотя размеры каждого файла малы по сравнению с размером и номером узла (500 МБ, выполняющимся внутри 8 узлов каждый с 10 ГБ памяти исполнителя).

в журнале рабочего узла стандартного вывода, я вижу непрерывные линии, как этот [GC2015-10-16T22: 31: 39.567 + 0000: [ParNew: 272655K-> 19K (306688K), 0.0292600 сек] 467995K-> 195361K (10451712K), 0.0293570 secs] [Times: user = 0.11 sys = 0.00, real = 0.03 secs]

Кажется, что рабочие прыгают, будучи GC'ed до смерти. Почему это должно произойти?

+0

Сколько из этих строк gc на один десятисекундный интервал? Примерно через 1/10 секунд это будет примерно правильным (1% от общего количества процессора). – javadba

ответ

1

не уверен точно сколько раз в секунду, но я нашел решение, которое является разумным.

В этом случае создается новый RDD для каждого файла, который запускает сбор предыдущих RDD. Я переписал код так, чтобы RDD был var и повторно использовал одну и ту же переменную для каждого цикла цикла. Теперь я все еще вижу линии GC, но пропускная способность в 10 раз выше.

Смежные вопросы