Нелепое использование VMEM при использовании Ray в кластере ⇐ Python

[Anonymous]

Первоначальная проблема:
Я тестирую многопроцессорный пакет Python под названием Ray для распараллеливания моего кода. Исходный код отлично работает на моем ноутбуке Core-i7-13800H, 32 ГБ ОЗУ. Однако при запуске в локальном кластере задание завершается сбоем, когда я указываю num_cpus (ключевое слово Ray) больше 40, несмотря на то, что из кластера было запрошено 50 процессоров и 200 ГБ ОЗУ. Для справки: я использовал num_cpus=18 на своем ноутбуке. STDOUT возвращает огромную рекламную информацию, которая, как мне кажется, может быть ошибкой OOM (см. ниже).

Код: Выделить всё

> ^[[36m(func_parallel pid=70267)^[[0m [2024-11-01 10:33:28,278 E 70267 75787] logging.cc:108: Unhandled exception: N5boost10wrapexceptINS_6system12system_errorEEE. what(): thread: Resource temporarily unavailable [system:11]
> ^[[36m(func_parallel pid=70115)^[[0m OpenBLAS blas_thread_init: pthread_create failed for thread 1 of 50: Resource temporarily unavailable
> ^[[36m(func_parallel pid=70115)^[[0m OpenBLAS blas_thread_init: RLIMIT_NPROC 16384 current, 16384 max
> ^[[36m(func_parallel pid=69306)^[[0m 2024-11-01 10:33:29.811669: F external/local_tsl/tsl/platform/default/env.cc:74] Check failed: ret == 0 (11 vs. 0)Thread tf_numa_-1_Eigen creation via pthread_create() failed.
> ^[[36m(func_parallel pid=69306)^[[0m *** SIGABRT received at time=1730482409 on cpu 55 ***
> ^[[36m(func_parallel pid=69306)^[[0m PC: @     0x14a9fbfa8cbb  (unknown)  raise
> ^[[36m(func_parallel pid=69306)^[[0m     @     0x14a9fcabc8c0  186786352  (unknown)
> ^[[33m(raylet)^[[0m A worker died or was killed while executing a task by an unexpected system error. To troubleshoot the problem, check the logs for the dead worker. RayTask ID: 4e9c3bd9b738a771af2ce9c4f66013ce9dbb521201000000 Worker ID: 52b96fe61ede380cde1d513fc65c222ba65a0100a2a1a8b00ad8f310 Node ID: ea8ebb2f21de741cf396d92301075881372f10000e39b7518e080cbb Worker IP address:  Worker port: Worker PID: Worker exit type: SYSTEM_ERROR Worker exit detail: Worker unexpectedly exits with a connection error code 2. End of file. There are some potential root causes. (1) The process is killed by SIGKILL by OOM killer due to high memory usage. (2) ray stop --force is called. (3) The worker is crashed unexpectedly due to SIGSEGV or other unexpected errors.

Вверх видно, что RES на ядро ​​составляет всего 1,5 ГБ, но колоссальные 92 ГБ VMEM на ядро, в результате чего общее использование VMEM для работы составляет более 2 ТБ! В коде нет ничего, что гарантировало бы такое интенсивное использование.
Я не могу поделиться исходным кодом, но я протестировал упрощенный код, чтобы проверить, нет ли утечки памяти, и воспроизвести это. без импорта всех остальных модулей и предварительной обработки данных.
Упрощенная задача:
Упрощенный код показан ниже, где распараллеленная функция принимает матрицу размером 10000x10000, умножает ее сама на себя, суммирует все элементы, добавляет ее в цикле и выводит суммированный результат. Я попробовал использовать пакет Python Multiprocessing, Ray Core и Ray Multiprocessing Pool.

Код: Выделить всё

import os
os.environ['RAY_DEDUP_LOGS'] = '0'
import numpy as np
import ray
from ray.util.multiprocessing import Pool

# Used by Ray Core
@ray.remote
def func_parallel(db):
a = 0
for _ in range(5):
a = a + np.sum(np.matmul(db, db))

print(a)
return a

# Used by Ray Multiprocessing Pool
# def func_parallel(db):
#     a = 0
#     for _ in range(5):
#         a = a + np.sum(np.matmul(db, db))

#     print(a)
#     return a

nloop = 50
mat = np.ones((10000, 10000))

# Tested with Ray Core
ray.init(num_cpus=40, object_store_memory=80*1024*1024)
db_ref = ray.put(mat)
task = [func_parallel.remote(db_ref) for _ in range(nloop)]
val = ray.get(task)

# Tested with Ray Multiprocessing Pool
# with Pool(ray_remote_args={'num_cpus': 40}) as pool:
#     val = pool.map(func_parallel, [mat for _ in range(nloop)], chunksize=1)

print(val)

Опять же, на моем ноутбуке это работает нормально, но по-прежнему потребляет более 60 ГБ VMEM на каждое ядро ​​кластера и может привести к сбою, когда num_cpus превышает определенное число. Единственный метод, который я нашел для управления этим нелепым числом, — это указать для object_store_memory минимально возможное значение (около 80 МБ), что снижает использование VMEM до 9 ГБ на ядро. Использование RES составляет всего 1 ГБ, что кажется правильным для размера матрицы (100 миллионов элементов двойной точности — чуть меньше 1 ГБ).
До сих пор не знаю, почему используется 9 ГБ, но ладно Я могу с этим жить, и это позволяет мне увеличить num_cpus. Указание object_store_memory в моем исходном коде снижает использование VMEM до 27 ГБ на ядро. Это значение колеблется от 5 до 27 ГБ (как сообщает top), и я не знаю, какому этапу кода это соответствует, поскольку мои операторы печати, похоже, поступают пакетами. Колебания могут быть связаны с политикой повторных попыток Рэя. Опять же, задание завершается неудачей, когда num_cpus превышает определенное число.
Вопросы:

• Задания не выполняются из-за высокой загрузки VMEM?
• Почему такая высокая загрузка VMEM?
• Что происходит, когда используя Ray в кластере, а не на моем ноутбуке? Оба запускают один и тот же код, и хотя мой ноутбук приличный, на нем нет 18 * 27 ГБ свободного места для этого безумного использования VMEM.

Подробнее здесь: https://stackoverflow.com/questions/791 ... -a-cluster