Наращивание памяти с помощью функции dask с большими промежуточными звеньями
У меня есть общий вопрос о dask.compute(), который вызван наращиванием памяти, которое я испытывал с этой функцией. Я использую dask.compute() и map_partitions() (пробовал с dask.distributed и dask.multiprocessing (позднее как с pool=ThreadPool и pool=multiprocessing.pool)), чтобы применить функцию, которая выполняет серию операции с кусками dask датафрейма. Выходные данные функции представляют собой относительно небольшую матрицу, но операции внутри функции включают действительно большие промежуточные матрицы. Несмотря на удаление этих промежуточных звеньев, со временем у меня нарастает память, что в итоге приводит к смерти моего ядра. Это заставляет меня задуматься о том, распределяет ли dask задания только на основе ожидаемого размера конечной выходной переменной, а не на большие вычисления внутри функции, что приводит к отправке слишком большого количества заданий и увеличению объема памяти. Это возможно? Спасибо за понимание того, что может пойти не так.
1 ответ
Существует ряд похожих проблем (например, https://github.com/dask/distributed/issues/1795 и других местах). Как и в этом вопросе, вы, возможно, захотите сначала запустить обычные инструменты мониторинга памяти Python, чтобы проверить, является ли это внутренним поведением.
По сути, люди испытывали накопление памяти при создании и удалении большого количества фреймов данных панд, и это, похоже, проблема панд, не связанная с dask, или, возможно, даже проблема malloc более глубокого уровня. Вы можете делать типичные вещи, такие как строго убедиться, что вы не будете сохранять ссылки в прямом эфире, и вы можете позвонить gc.collect() в вашем коде.