Ошибка gpu недостаточно памяти

Обновлено: 06.07.2024

I have been experiencing an error on systems with multiple GPUs. When GPU0 is fully utilized by another process, I get RuntimeError: cuda runtime error (2) : out of memory .

It seems that torch.nn.Module.cuda() transfers data not only to my specified GPU, but also GPU0, whose memory is already being used.

I can reproduce this error using the below code (memory on GPU0 should be fully utilized by another process):

I am using GPU5, but the same process 34873 is also using memory on GPU0.

It looks like in the device class of torch/cuda/init.py, the prev_idx is being reset to 0 and then torch._C._cuda_setDevice is setting the device number to 0 upon exit.

torch/cuda/init.py:110

The text was updated successfully, but these errors were encountered:

Even when I specify the cuda device for all my transfers, there is still memory being used on GPU0, e.g.

Is this the right behavior?

More specifically, model.cuda(5) transfers data onto GPU0 (the default), but the variable transfers do not, the variables seem to only go onto GPU5 when I specify the device number.

SsnL commented Nov 4, 2017

@lucylw Yes this is the intended behavior. Since PyTorch still sees your GPU 0 as first in CUDA_VISIBLE_DEVICES, it will create some context on it. If you want your script to completely ignore GPU 0, you need to set that environment variable. e.g., for it to only use GPU 5, do CUDA_VISIBLE_DEVICES=5 python my_script.py . However, be noted that in the script GPU 5 is really referred to as device 0.

apaszke commented Nov 4, 2017

Still, I thought we're only initializing contexts on devices that are actually getting used (in the last snippet). I don't think we should create one on GPU0 in this case. It's worth looking into that.

SsnL commented Nov 5, 2017

@apaszke From my experience with 0.2.0, it always creates

250MB context on first visible GPU, no matter if that GPU is used or not.

apaszke commented Nov 5, 2017

That's weird, I don't think it should be like this

It looks like in the context-manager in torch/cuda/__init__.py , the prev_idx gets reset in __enter__ to the default device index (which is the first visible GPU), and then it gets set to that upon __exit__ instead of to -1. So the context first gets created on the specified GPU (i.e. GPU5), then some more context gets created on GPU0, and then all the variable transfers go back to GPU5.

csarofeen commented Nov 6, 2017

Shouldn't enter/exit only get called with a 'with' statement?
Does this still happen if your first call (before using any cuda calls) torch.cuda.set_device(devID)?

There are a bunch of things in PyTorch that can currently lead to initialization of a context on the first visible GPU; things like CPU-GPU copies and .tolist() all need to be inside with torch.cuda.device_of(tensor): blocks. None of this is a problem if you use torch.cuda.set_device but the devs typically recommend CUDA_VISIBLE_DEVICES instead.

It has known conflicts with multi-process NCCL (as in it doesn't work)

soumith added this to distributed/multiGPU in Issue Categories Dec 1, 2017

I met the same problem using Pytorch 0.4.1. I have two GTX 1080Ti GPUs (11GB RAM for each one). When I run a training code on GPU0, it's OK. When I run the training code on GPU1 by setting CUDA_VISIBIE_DEVICES, the program reported CUDA OUT OF MEMORY error.

It's weird since GPU0 actually has less free memory since it's connected to the monitor.

Free GPU memory before running the training code:

After running the training code on GPU0:

Error message when running on GPU1:

soumith commented Mar 27, 2019

@TomHeaven did you set CUDA_VISIBLE_DEVICES outside the python process? if that's the case pytorch should not even have driver-level access to your GPU0.

TomHeaven commented Mar 27, 2019

Yes, I did exactly the same way. And if I restart the computer, GPU 1 sometimes can run the code without problem.

Just tried this and the behaviour is really perplexing. I am working on two gpus system shared with my colleagues. Cuda:1 is in use by my colleague and though cuda:0 is mostly empty(8300MBfree), I get OOM error.

Let me know if you need more information.

@gchanan Please ignore my comment earlier. I have been informed just now by the owner of the system, that due to some glitch the gpus id have been reversed. So, RTX is actually gpu id 1, and not 0. and nvidia-smi gives wrong info. I am really sorry for wasting your time.

Note: I have just copied over information from supervisor to you directly. Just to not look into my issue and waste time, but I am yet to confirm the supervisor comments myself yet. I will confirm this tonight as soon as I have system access.

deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 10.0, CUDA Runtime Version = 10.0, NumDevs = 2, Device0 = TITAN V, Device1 = GeForce RTX 2080 Ti

Turns out the issue is discrepancy between how nvidia-smi and rest of nvidia driver works.

Можно не напрягатся-там всё тоже самое. Перепробовал все репаки какие есть. Играть то в принципе можно и с объявой этой дурацкой.

видео драйвер..гы..гы он помнит версию ОС; серию и свои видеокарты.
какая ЕЩЁ драйверу нужна память? нажимай Enter и вперёд
(странно, но там где мочилово в Суде, ни разу не выскочило это предупреждение)
Играл, ради интереса, на A10 7800, ОЗУ- ddr3-1600mhz 8 gb, (офис-ящик жены, без видюшки) так:
РабСтол поставил 1280х720 - а то будет не на весь экран
в игре:
video quality Profile низкий
aspect ratio 16:9
Resolution 1280x720 разрешение(как и на рабочем столе)
window mode windowed оконный режим(без рамки)
vernical sync off
motion blur off
anti aliasng off
colorbling mode off
> advanced settings
apply changes

Доп параметры video:
filed of wiew 90 Поле зрения
lights medium Качество света
sadows low тени
particles medium Качество и количество частиц
Directional Occlusion off Добавляет тени к контуру объектов
reflections low Качество отражений
decals medium Качество и близость деталей
motion blur medium Размытость свечения
image streaming low Потоковое изображение
water quality low Качество воды
volumetric medium Объемное качество
material anido filter Trilinear
decal filtering Trilinear
lightmap aniso filter Trilinear
image aniso filter Trilinear
LOD switch low даль прорисовки
Deferred rendering low Отложенный рендеринг
>GPU Culling On
chromatic aberration off размытие по краям экрана
depth of filed off
DoF anti aliasing off
Sarpening 2.0 резкость изображения
Film Grain 0.0
resolution scale off
Manual Scaling 1.00
Show performance metric мониторинг на экран по желанию
30-40 fps -- мониторинг самой игры.
ps: игра классно оптимизирована, картинка на Любых настройках графона оч.приличная. (Накатал для тех у кого плоховато с железом, но и другим знать не вредно)

Под конец 2019 года у некоторых майнеров, использующих операционную систему Windows 10 появились проблемы с майнингом Ethereum на видеокартах компании Nvidia GTX1050Ti (имеет на борту 4 Гб памяти). В то же время видеокарты производства AMD с аналогичным объемом памяти прекрасно работают и не причиняют никаких неудобств майнерам.

Почему у зеленых видеокарт появились такие проблемы? Ведь обычно Nvidia славилась надежностью своих изделий и за это имеет большую армию своих поклонников.

В этой статье рассматриваются проблемы, связанные с появлением ошибок при майнинге на видеокартах Nvidia с объемом видеопамяти на 600-700мегабайт большим, чем текущий размер блока данных DAG, который используется при майнинге на алгоритме Ethash.

Почему у видеокарт Nvidia GTX 1050Ti возникают проблемы при майнинге эфира?

Эта проблема связана с неправильным распределением ресурсов архитектуры графических драйверов для видеокарт Windows Display Driver Model (WDDM) в операционной системе Windows 10.

Скриншот рига под управлением Windows 7 с GTX1050Tiпри майнинге эфира на 295 эпохе (размер DAG 3300 Mb):

При майнинге в ОС Виндовс 10 на четырехгиговых картах производства Нвидиа резервируется очень большой объем памяти, в связи с этим на ней раньше всего возникает ошибка «CUDA 11, cannot write big DAG», при которой объем доступной памяти GPU оказывается недостаточным для записи DAG.

Скриншот ошибки error CUDA 11, cannot write big DAG:

У видеокарт AMD при нехватке памяти в этом случае будет возникать ошибка opencl error -4 0 cannot create dag on gpu.

Со второй половины 2020 года проблемы с майнингом на четырехгиговых картах начнутся у всех владельцев видеокарт с 4 Гб видеопамяти, так как тогда размер блока данных DAG станет все ближе приближаться к 4Гб. Подробнее об этой проблеме можно почитать в статье «Перспективы майнинга эфира на четырехгиговых видеокартах».

Как устранить ошибку CUDA ERROR 11 и запустить майнинг на GTX1050/1050Ti?

Для достижения наиболее продолжительного времени майнинга эфира нужно уменьшить до предела резервирование видеопамяти операционной системой. В Windows 10 это можно сделать до предела разгрузив видеопамять и установив самые экономичные драйвера. Об этом можно почитать в вышеупомянутой статье. В Windows 10 это даст возможность майнить еще несколько дней/недель.

Для кардинального решения проблемы с освобождением видеопамяти и обеспечения самого продолжительного времени майнинга эфира на четырехгиговых картах нужно переходить на Linux-подобную ОС, например, HiveOS, Ubuntu, SMOS и т.д. Эти системы резервируют в разы меньше памяти, чем даже Windows 7 или 8.1, что продлит время майнинга эфира до начала 2021 года.

Если нет желания заниматься установкой линуксподобных осей, то можно установить операционную систему Windows 7или 8/8.1, настроить ее на максимальное быстродействие и спокойно майнить эфир, как минимум до второй половины 2020 года. Это возможно ьлагодаря тому, что раньше компания Microsoft тщательнее подходила к вопросу распределения ресурсов и ее операционки были менее прожорливыми.

Какая ОС семейства Windows меньше всего расходует видеопамять?

Для сравнения прожорливости разных ОС Windows, рассмотрим данные по потреблению видеопамяти разными ОС при майнинге эфира на GTX1050Ti на 295 эпохе (раз мер DAG равен 3300 Mb), в мегабайтах:

Потребление видеопамяти при майнинге эфира на GTX1050Ti в Windows 7 (драйвер 440.97) составляет 3594 Мб:

В Windows 8.1 потребление памяти составляет 3453 Мб (драйвера 419.35):

В Windows 10 LTSC на драйверах 441.08 при майнинге эфира на 295-й эпохе используется 3621 Мб:

Как видно, потребление памяти в разных ОС отличается в разы (драйвера также вносят свою лепту, но небольшую – порядка 10-20 Мб).

В Windows 8.1 используется на 168 Мб памяти меньше, чем у Windows 10, что позволяет майнить на 168/8=21 эпоху дольше (порядка трех месяцев)

На видеокартах Radeon RX4xx/5xx-серий в Windows 10 LTSC (драйвера 18.6.1) при тех же условиях расходуется 3472 Мб памяти (на 122 Мб меньше, чем у GTX1050Ti под Windows 7, но на 19 Мб больше, чем в Windows 8.1).

Как видно из представленных результатов, разные ОС и драйвера потребляют память по разному. Можно отметить, что Windows 8.1 является лучшей системой по экономичности резервирования видеопамяти для видеокарт Nvidia. Нужно также учитывать то, что меньше всего потребляют видеопамять драйвера Nvidia версий 388.13/388.71 и 419.35.

Для достижения большей экономичности в потреблении видеопамяти можно перейти с Клеймора 15.0 на Феникс майнер 4.7, так как последний потребляет немного меньше памяти.

Заключение

Установка Windows 7 или 8.1 проста и принесет новую жизнь владельцу компьютера, порадовав его намного большим быстродействием, чем у любой версии Windows 10. В качестве бонуса он получит выигрыш в виде освобожденных 150 мегабайт видеопамяти и дополнительно несколько месяцев майнинга эфира.

Перефразируя классика «…если есть в запасе сотня мегабайт, значит все не так уж плохо на сегодняшний день…»