Наборы.NET и "куча" для больших объектов (LOH)
Я видел такое поведение от искры, когда время, затрачиваемое на одно задание, очень мало. По какой-то причине планировщик, похоже, предполагает, что задание будет выполнено быстрее без дополнительных накладных расходов на распространение, поскольку каждая задача завершается так быстро.
Пару попыток:
- Попробуйте
.coalesce()уменьшить количество разделов, чтобы каждый раздел работал дольше (предоставлено, это может привести к шагу шага и может увеличить общее время работы, у вас есть срок действия) - Настройте
spark.locality.wait*настройки здесь . Если каждая задача занимает меньше времени ожидания по умолчанию3s, то, возможно, планировщик просто пытается сохранить существующие слоты заполненными и никогда не имеет возможности выделить больше слотов.
Мне еще предстоит отследить точно , что вызывает эту проблему, поэтому это всего лишь предположения и догадки, основанные на моих собственных наблюдениях в моем собственном (гораздо меньшем) кластере.
4 ответа
Объекты будут только храниться на LOH, если они будут более чем 85 000 байтов. Большой список (особенно структур) будет часто выделяться здесь.
Однако Словарь менее вероятен, так как они хранят массив блоков, поэтому если генерирование достаточного количества блоков так массив не становится> 85 000 байтов, это маловероятно. Список 40k элементов будет сохранен на LOH, даже если они будут классами (так как ссылки на объект в каждом элементе заставят список быть 160k на x86, 320k в x64 системах). Отдельные элементы будут на стандартной "куче", тем не менее, так будет уплотнен, и т.д.
При использовании двунаправленного связанного списка вместо стандартного Списка очень маловероятно, что он будет сохранен на LOH. Каждый элемент списка будет маленьким (просто единственный узел со ссылками на следующие/предыдущие узлы), таким образом, никакой отдельный объект не будет> 85k байты.
Для получения дополнительной информации на LOH, это - замечательная запись в блоге.
Список реализован как массив. Как таковой массив будет помещен в LOH, но сам Объект списка не будет.
То же в основном относится к Словарю также. Это также использует массив блоков внутренне, которые в основном хранят пары ключ/значение, которые Вы добавляете.
System.Collections.Generic.List реализован как массив внутренне, не связанный список. И да, если размер набора будет большим, то он будет выделен на "куче" для больших объектов (обратите внимание, что размер массива важен, если у Вас будет небольшой массив больших ссылочных типов, то он не будет выделен на LOH).
Словарь имеет O (ЗАРЕГИСТРИРУЙТЕ N), вектор для ключа/значения, таким образом, в 40K + возражает Вашему довольно безопасному. Столь же сказанный здесь, прежде чем Список реализован как массив, таким образом, большой список находится действительно на LOH. Можно проверить, возражаете ли Вы, находится на LOH использование SOS.