DASK Memory Per Worker Guide - PullRequest
Новая
       11

DASK Memory Per Worker Guide

0 голосов
/ 20 сентября 2019

В настоящее время я работаю над рефакторингом некоторой устаревшей аналитики в Python / DASK, чтобы показать эффективность этого решения в будущем.

Я пытаюсь настроить демонстрационный сценарий и у меня возникают проблемы спамяти и хотелось бы несколько советов.

Мой сценарий;Мои данные разбиты на сжатые файлы 52 gzip на S3, каждый из которых, несжатый в памяти, составляет около 100 МБ, что дает общий размер набора данных ~ 5,5 ГБ и ровно 100 000 000 строк.

Мой планировщик находится на T2.Medium (4GB / 2vCPU), как и мои 4 рабочих.Каждый рабочий выполняется с 1 процессом, 1 потоком и пределом памяти в 4 ГБ, т. Е. dask-worker MYADDRESS --nprocs 1 --nthreads=1 --memory-limit=4GB.

Теперь я извлекаю файлы паркета и немедленно перераспределяю столбец таким образом, что яв конечном итоге примерно 480 разделов каждый из ~ 11MB.

Затем я использую map_partitions для основной работы.Это хорошо работает для небольших наборов данных, однако для набора данных 100 mil мои работники продолжают падать из-за нехватки памяти.Что я здесь не так делаю?Для информации, специфичной для реализации, функции, которую я передаю в map_partitions, иногда может потребоваться примерно 1 ГБ, из-за того, что по сути является перекрестным соединением на фрейме данных раздела.

Я не понимаю, что делать с архитектурой DASK?Между моим планировщиком и четырьмя моими работниками имеется 20 ГБ памяти для работы, но этого оказывается недостаточно.Из того, что я прочитал из документации DASK, является то, что, если каждый раздел и то, что вы делаете с этим разделом, помещается в память рабочего, то с вами все должно быть в порядке?

Разве 4 ГБ просто нетдовольно?Нужно ли больше для обработки планировщика / межпроцессного взаимодействия?

Спасибо за чтение.

1 Ответ

0 голосов
/ 21 сентября 2019

См. https://docs.dask.org/en/latest/best-practices.html#avoid-very-large-partitions

Я скопирую здесь текст для удобства

Ваши куски данных должны быть достаточно маленькими, чтобы многие из них сразу помещались в доступную память работника.Вы часто управляете этим, когда выбираете размер раздела в Dask DataFrame или размер чанка в Dask Array.

Dask, скорее всего, будет манипулировать таким же количеством чанков параллельно на одном компьютере, сколько у вас ядер на этом компьютере.Таким образом, если у вас есть блоки по 1 ГБ и десять ядер, то Dask, скорее всего, будет использовать не менее 10 ГБ памяти.Кроме того, для Dask характерно иметь в 2-3 раза больше блоков, доступных для работы, чтобы у него всегда было над чем работать.

Если у вас есть машина с 100 ГБ и 10 ядрами, вы можетехочу выбрать куски в диапазоне 1 ГБ.У вас есть место для десяти блоков на ядро, что дает Dask здоровый запас без слишком маленьких задач

...