Гугл коллаб ошибка

Ваш сеанс завершился с ошибкой после использования всей доступной оперативной памяти в Google Collab

У меня есть 6 файлов tsv с большими данными, которые я читаю в фреймы данных в Google Collab. Однако файлы слишком большие, и Google Colab не может с этим справиться.

Ошибка: сеанс завершился сбоем после использования всей доступной оперативной памяти. Журналы выполнения говорят следующее:

Как Google Collab может лучше справляться с Ram? Размер всех моих tsv-файлов, вместе взятых, составляет 2800 МБ. Пожалуйста, порекомендуйте!

Google colab обычно предоставляет бесплатную оперативную память на 12 ГБ, но мы можем увеличить ее, заплатив Google что угодно.

Написав всего три строки кода, вы можете увеличить объем оперативной памяти с 12 ГБ до 25 ГБ.

a = [] while (1): a.append (‘1’)

Попробуйте, это может помочь.

Самый простой способ — использовать данные только по мере их использования и удалить их из памяти. Это можно сделать принудительно, заставив сборщик мусора освободиться (см. Тему здесь [https://stackoverflow.com/questions/1316767/how-can-i-explicitly-free-memory-in-python]) 1

Если вы хотите расширить свою оперативную память в Colab, раньше был взлом, при котором вы намеренно вызвали нехватку оперативной памяти, а затем он предложит вам более высокое время работы ОЗУ. Эту опцию также можно выбрать с помощью Colab pro в разделе «Время выполнения» -> «Изменить тип времени выполнения». За 10 долларов в месяц Colab Pro вполне может стать для вас хорошим вариантом.

Я видел здесь этот хакер, но вкратце просто добавляю что-нибудь в массив в цикле while, пока ОЗУ не будет исчерпано.

У Google Colab заканчивается ОЗУ (12 ГБ) при попытке создать набор данных tf.image.resize

В приведенном выше коде (последняя строка) я пытаюсь изменить размер всего набора данных (35000 элементов). Но Google Colab исчерпывает всю оперативную память. Есть ли другой способ подойти к этой проблеме, пожалуйста?

2 ответа

Попробуйте сделать это итеративно с tf.data.Dataset . Размер изображений будет изменяться только при итерации набора данных, по одному пакету за раз. Таким образом, он не будет создавать новый набор данных в памяти.

Есть ли другой способ подойти к этой проблеме, пожалуйста?

Используйте меньше оперативной памяти. Я не пытаюсь казаться снисходительным, но проблема в том, что вы используете слишком много оперативной памяти, и нет другого выхода, кроме как использовать ее меньше. Каждый раз, когда вы присваиваете значение переменной в Python, он должен выделить память для хранения этого значения. Если вы будете делать это постоянно, не освобождая память, вы столкнетесь с этой проблемой.

Что касается того, как вы должны подойти к этой конкретной проблеме, подумайте, какие данные вам нужно загрузить в память, чтобы ваш код работал, и избегайте загрузки данных, которые не нужны. Например, похоже, что у вас есть DataFrame, df , где вы храните необработанные данные, список, images , где вы храните подмножество этих данных, и список, new_img , где вы храните обработанные данные. По сути, вы дублируете эти данные снова и снова, не выпуская их. Вместо этого вам следует избегать копирования данных (например, вам не нужно копировать данные DataFrame в список images ; просто перебирайте их непосредственно в DataFrame) и освобождая данные, которые вы больше не используете (например, , если вам не нужны предварительно обработанные данные pixels в DataFrame после создания списка new_img , удалите DataFrame / Series с помощью оператора del ).

Вы также можете полностью отказаться от предварительной обработки этих данных (т.е. обрабатывать их по мере необходимости), или работать с ними в пакетном режиме, или уменьшить размер данных, чтобы использовать меньше памяти и т. Д. Есть много способов избежать этих проблем.

Google Colaboratory: вводящая в заблуждение информация о его графическом процессоре (некоторым пользователям доступно только 5% оперативной памяти)

обновление: этот вопрос связан с Google Colab «Настройки ноутбука: Аппаратный ускоритель: GPU». Этот вопрос был написан до того, как была добавлена ​​опция «TPU».

Прочитав несколько восторженных объявлений о том, что Google Colaboratory предоставляет бесплатный графический процессор Tesla K80, я попытался запустить на нем урок fast.ai, чтобы он никогда не завершился — быстро закончилась память. Я начал выяснять, почему.

Суть в том, что «бесплатная Tesla K80» не «бесплатна» для всех — для некоторых «бесплатна» лишь небольшая ее часть.

Я подключаюсь к Google Colab из западного побережья Канады и получаю только 0,5 ГБ из того, что должно было быть 24 ГБ оперативной памяти графического процессора. Остальные пользователи получают доступ к 11 ГБ оперативной памяти графического процессора.

Очевидно, что 0,5 ГБ ОЗУ графического процессора недостаточно для большинства операций ML / DL.

Если вы не уверены, что получите, вот небольшая функция отладки, которую я собрал вместе (работает только с настройкой графического процессора ноутбука):

Выполнение его в блокноте jupyter перед запуском любого другого кода дает мне:

Удачливые пользователи, получившие доступ к полной карте, увидят:

Видите ли вы какой-нибудь изъян в моих расчетах доступности оперативной памяти графического процессора, заимствованных из GPUtil?

Можете ли вы подтвердить, что вы получите аналогичные результаты, если запустите этот код в блокноте Google Colab?

Если мои расчеты верны, есть ли способ получить больше этой оперативной памяти графического процессора в бесплатной коробке?

обновление: я не уверен, почему некоторые из нас получают 1/20 того, что получают другие пользователи. например, человек, который помог мне отладить это, из Индии, и он получает все!

Примечание : пожалуйста, не присылайте больше предложений о том, как убить потенциально застрявшие / выходящие из строя / параллельные ноутбуки, которые могут потреблять части графического процессора. Независимо от того, как вы это делаете, если вы находитесь в той же лодке, что и я, и должны были запустить код отладки, вы увидите, что вы все еще получаете в общей сложности 5% ОЗУ графического процессора (на момент этого обновления).

Итак, чтобы предотвратить еще одну дюжину ответов, предполагающих недействительность в контексте предложения этого потока для! Kill -9-1, давайте закроем этот поток:

На момент написания этой статьи Google просто предоставляет лишь 5% графического процессора одним из нас, а другим — 100%. Период.

Обновление декабрь-2019: проблема все еще существует — ответы на этот вопрос все еще продолжаются.

Обновление за март-2019: год спустя сотрудник Google @AmiF прокомментировал положение вещей, заявив, что проблемы не существует, и любому, у кого, похоже, есть эта проблема, необходимо просто сбросить время выполнения, чтобы восстановить память. Тем не менее, голоса продолжаются, что для меня говорит о том, что проблема все еще существует, несмотря на предложение @ AmiF об обратном.

Обновление за декабрь 2018 г .: у меня есть теория, что у Google может быть черный список определенных учетных записей или, возможно, отпечатков пальцев браузера, когда его роботы обнаруживают нестандартное поведение. Это могло быть полным совпадением, но в течение некоторого времени у меня была проблема с Google Re-captcha на любом веб-сайте, который требовал этого, где мне приходилось решать десятки головоломок, прежде чем меня пропускали, часто на выполнение у меня ушло 10+ минут. Так продолжалось много месяцев. Внезапно, начиная с этого месяца, у меня вообще нет головоломок, и любая повторная капча Google решается одним щелчком мыши, как это было почти год назад.

И зачем я рассказываю эту историю? Ну потому что при этом мне дали 100% RAM GPU на Colab . Вот почему я подозреваю, что если вы находитесь в теоретическом черном списке Google, то вам не доверяют предоставление большого количества ресурсов бесплатно. Интересно, найдет ли кто-нибудь из вас такую ​​же корреляцию между ограниченным доступом к графическому процессору и кошмаром Re-captcha. Как я уже сказал, это тоже могло быть полным совпадением.