Multiprocessing. Через некоторое время очередь замедляется, совместно используются большие объемы данных в распределенно ⇐ Python

[Anonymous]

У меня возникает множество проблем с обменом большими объемами данных между несколькими процессами в распределенной системе обучения с использованием pytorch на моем локальном компьютере. При запуске программы все работает нормально, но через некоторое время действия по передаче данных через многопроцессорность. Очереди сильно тормозят(

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

.put(..)

и .get(..)).
Я уже несколько недель пытаюсь это исправить, попробовал несколько разных подходов с torch.multiprocessing.Queue вместо стандартного пакета, а также с помощью Manager.Lists. Я пробовал отдельные очереди между процессами, а также одну с несколькими производителями. Мне кажется, нет разницы. Я даже начал следить за своим оборудованием, потому что беспокоюсь, что это может быть проблема с оперативной памятью или что-то в этом роде, но понятия не имею, что еще попробовать. К сожалению, я также не могу предоставить исходный код проекта или минимальный пример для воспроизведения.
Вот еще информация.

• ЦП: Intel(R) Core(TM) i9-14900K
• Графический процессор: NVIDIA GeForce RTX 4090 24 ГБ, версия драйвера: DCH 552.22
• ОЗУ: 192 ГБ DDR5, 5200 МГц
• Python 3.12.3
• pip 24.0
• torch 2.3.0+ cu121

Архитектура выглядит следующим образом:
[img]https://i.sstatic .net/4hGg1DXL.png[/img]

• имеется 20 процессов Actor, каждый из которых моделирует 6 сред и собирает образцы данных
  < li>сэмплы сжимаются и передаются через очередь в буфер воспроизведения
• буфер воспроизведения формирует пакеты сэмплов и передает их через очередь трем процессам распаковки
• Распаковщики в конечном итоге предоставляют пакеты учащемуся.
• Учащийся периодически отправляет обновления весов актерам и обновляет приоритеты в буфере воспроизведения.

Я добавил сжатие в памяти, чтобы уменьшить количество операций ввода-вывода и объем памяти в обмен на вычисления. Первоначально сжатие выполнялось в буфере воспроизведения, но оно работало не очень хорошо, поскольку байты, отправленные от актеров, были примерно в 5 раз больше, что еще больше замедляло очереди. Кроме того, Replay Buffer не мог самостоятельно распаковывать образцы, чтобы не отставать от Learner, поэтому мне пришлось добавить Uncompressors.
Я добавил журналирование производительности. Учтите следующие наблюдения:

Продолжительность обучения остается примерно постоянной, но получение обучающих пакетов из очереди распаковки занимает гораздо больше времени (несколько секунд для 1 пакета), чем дольше продолжается обучение (поскольку в нем явно недостаточно пакетов).

Здесь вы можете увидеть время, необходимое трем процессам распаковки для получения данных из очередь, измеряемая следующим образом:

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

t_get = time.time()
item = self.q_samples_in.get(timeout=5)
t_get = time.time() - t_get

Она постоянно увеличивается до нескольких секунд на каждый пакет, хотя размер (в байтах) передаваемых данных остается постоянным для каждого пакета. Можно также заметить, что вначале проблем нет, но после первых 500 пакетов ситуация начинает ухудшаться.

Продолжительность добавления образцов в буфер, а также выборки здесь не является проблемой. Ожидается увеличение продолжительности пакетов выборки, поскольку объем данных растет.
На правых диаграммах можно увидеть проблему, когда рост буфера и скорость обучения замедляются (это правильно, из-за планового регулирования Actor, потому что обучается недостаточно сэмплов, поскольку распаковщики получают недостаточно данных из буфера воспроизведения). Слева также можно увидеть, что количество времени, необходимое для получения данных от Актеров, также увеличивается, хотя этим временем можно пренебречь.
Самое странное — это Третий график выделен синим цветом, где время, необходимое для добавления выборочной партии в очередь для распаковщиков, в этом случае падает практически до 0 с примерно на шаге 500 (т. е. семплы добавляются в очередь мгновенно?) примерно в это же время распаковщики начать испытывать трудности с получением данных в разумные сроки. В то время как на другом конце распаковщикам требуется много времени, чтобы получить данные до такой степени, что учащемуся приходится их ждать. Примечание. В этом прогоне это явление произошло примерно на шаге 500, но в других прогонах это может быть 150 000, я не вижу закономерности.
Что является причиной этого? Почему вначале он работает быстро, а затем внезапно замедляется, чем дольше продолжается обучение?
Я контролировал свое оборудование (загрузка процессора, частота, память, файлы подкачки, температура и т. д.) - Насколько мне известно, ничего необычного. Я отслеживал использование оперативной памяти на предмет утечек памяти, но, как и следовало ожидать, оно стабильное. Я также глубоко копирую все элементы перед отправкой и при их получении, а также удаляю неиспользуемые переменные.
Иногда удается восстановить, но часто этого не происходит, и он сохраняется о том, что становится хуже. Что я заметил выше, так это то, что (в данном случае) примерно на шаге 500 во всех процессах передача данных начинает одновременно замедляться, поэтому я беспокоюсь, что это может быть проблема с моей оперативной памятью (хотя компьютер построен новый и ему едва исполнилось 2 месяца). Кроме того, при запуске любых других приложений система работает как обычно, что указывает на то, что это как-то связано с самим процессом Python. Я знаю, что очереди довольно сложны, но я не могу сказать, какая логика может вызывать такое поведение.
Кто-нибудь знает, что является причиной этого и как я могу это исправить?
Я благодарен за любой отзыв!
— Т

Подробнее здесь: https://stackoverflow.com/questions/784 ... ts-of-data