Google Colaboratory: wprowadzające w błąd informacje o jego GPU (tylko 5% pamięci RAM dostępne dla niektórych użytkowników)

111

aktualizacja: to pytanie jest związane z „Ustawieniami notebooka: Akcelerator sprzętowy: GPU” Google Colab. To pytanie zostało napisane przed dodaniem opcji „TPU”.

Czytając wiele podekscytowanych ogłoszeń o Google Colaboratory dostarczającym darmowy procesor graficzny Tesla K80, próbowałem działać szybko. A lekcja na ten temat, aby nigdy się nie skończyła - szybko zabrakło pamięci. Zacząłem się zastanawiać, dlaczego.

Najważniejsze jest to, że „bezpłatna Tesla K80” nie jest „bezpłatna” dla wszystkich - dla niektórych tylko niewielka jej część jest „bezpłatna”.

Łączę się z Google Colab z Zachodniego Wybrzeża Kanady i otrzymuję tylko 0,5 GB z tego, co powinno być 24 GB pamięci RAM GPU. Inni użytkownicy uzyskują dostęp do 11 GB pamięci RAM GPU.

Najwyraźniej 0,5 GB pamięci RAM GPU jest niewystarczające dla większości zadań ML / DL.

Jeśli nie jesteś pewien, co otrzymujesz, oto mała funkcja debugowania, którą zeskrobałem razem (działa tylko z ustawieniem GPU notebooka):

# memory footprint support libraries/code
!ln -sf /opt/bin/nvidia-smi /usr/bin/nvidia-smi
!pip install gputil
!pip install psutil
!pip install humanize
import psutil
import humanize
import os
import GPUtil as GPU
GPUs = GPU.getGPUs()
# XXX: only one GPU on Colab and isn’t guaranteed
gpu = GPUs[0]
def printm():
 process = psutil.Process(os.getpid())
 print("Gen RAM Free: " + humanize.naturalsize( psutil.virtual_memory().available ), " | Proc size: " + humanize.naturalsize( process.memory_info().rss))
 print("GPU RAM Free: {0:.0f}MB | Used: {1:.0f}MB | Util {2:3.0f}% | Total {3:.0f}MB".format(gpu.memoryFree, gpu.memoryUsed, gpu.memoryUtil*100, gpu.memoryTotal))
printm()

Wykonanie go w notebooku jupyter przed uruchomieniem jakiegokolwiek innego kodu daje mi:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util  95% | Total 11439MB

Szczęśliwi użytkownicy, którzy uzyskają dostęp do pełnej karty, zobaczą:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 11439MB | Used: 0MB | Util  0% | Total 11439MB

Czy widzisz jakąś lukę w moich obliczeniach dostępności pamięci RAM na GPU, pożyczonej od GPUtil?

Czy możesz potwierdzić, że uzyskasz podobne wyniki, jeśli uruchomisz ten kod na notatniku Google Colab?

Jeśli moje obliczenia są prawidłowe, czy jest jakiś sposób, aby uzyskać więcej pamięci RAM GPU w darmowym pudełku?

aktualizacja: nie jestem pewien, dlaczego niektórzy z nas otrzymują 1/20 tego, co otrzymują inni użytkownicy. np. osoba, która pomogła mi w debugowaniu tego, pochodzi z Indii i dostaje wszystko!

Uwaga : nie wysyłaj więcej sugestii, jak zabić potencjalnie zablokowane / niekontrolowane / równoległe notebooki, które mogą zużywać części GPU. Bez względu na to, jak go pokroisz, jeśli jesteś na tej samej łodzi co ja i miałeś uruchomić kod debugowania, zobaczysz, że nadal masz łącznie 5% pamięci RAM GPU (nadal w tej aktualizacji).

stason
źródło
Jakieś rozwiązanie tego problemu? dlaczego podczas robienia otrzymuję różne wyniki! cat / proc / meminfo
MiloMinderbinder
Tak, ten sam problem, tylko około 500 MB pamięci RAM GPU ... mylący opis :(
Naveen
2
Wypróbuj narzędzia IBM do analizy danych typu open source (cognitiveclass.ai), ponieważ mają one również darmowy procesor graficzny z notebookami jupyter.
AQ
Przywróciłem to pytanie do stanu, w którym faktycznie jest w nim pytanie . Jeśli przeprowadziłeś więcej badań i znalazłeś odpowiedź, odpowiednie miejsce znajduje się w polu odpowiedzi. Nieprawidłowe jest aktualizowanie pytania rozwiązaniem.
Chris Hayes
@ChrisHayes, rozumiem twój zamiar, ale to nie jest w porządku, ponieważ twoje wycofanie usunęło całą masę istotnych szczegółów, które teraz zniknęły. Jeśli chcesz zasugerować lepsze sformułowanie, które lepiej pasuje do zasad tej społeczności, zrób to, ale w przeciwnym razie cofnij wycofanie. Dziękuję Ci. ps już wysłałem odpowiedź .
stason

Odpowiedzi:

42

Aby więc zapobiec kolejnemu tuzinowi odpowiedzi sugerujących nieprawidłowe w kontekście tej sugestii wątku! Kill -9-1, zamknijmy ten wątek:

Odpowiedź jest prosta:

W chwili pisania tego tekstu Google po prostu przekazuje tylko 5% GPU niektórym z nas, podczas gdy innym 100%. Kropka.

Aktualizacja z grudnia 2019 r .: Problem nadal istnieje - głosy za to pytanie nadal trwają.

Aktualizacja z marca 2019 r .: Rok później pracownik Google @AmiF skomentował stan rzeczy, stwierdzając, że problem nie istnieje, a każdy, kto wydaje się mieć ten problem, musi po prostu zresetować swoje środowisko wykonawcze, aby odzyskać pamięć. Jednak głosy poparcia trwają, co dla mnie oznacza, że ​​problem nadal istnieje, pomimo sugestii @ AmiF, że jest inaczej.

Aktualizacja z grudnia 2018 r .: Mam teorię, że Google może mieć czarną listę niektórych kont lub być może odciski palców przeglądarki, gdy jego roboty wykryją niestandardowe zachowanie. To może być całkowity zbieg okoliczności, ale od dłuższego czasu miałem problem z Google Re-captcha na każdej stronie, która tego wymagała, gdzie musiałem rozwiązać dziesiątki zagadek, zanim pozwolono mi przejść, często co zajmuje mi ponad 10 minut. Trwało to wiele miesięcy. Nagle od tego miesiąca nie dostaję żadnych łamigłówek, a każda re-captcha w Google jest rozwiązywana za pomocą jednego kliknięcia myszą, tak jak to było prawie rok temu.

A dlaczego opowiadam tę historię? Cóż, ponieważ w tym samym czasie otrzymałem 100% pamięci RAM GPU na Colab . Dlatego podejrzewam, że jeśli jesteś na teoretycznej czarnej liście Google, nie ufasz, że otrzymasz wiele zasobów za darmo. Zastanawiam się, czy któryś z was znalazł tę samą korelację między ograniczonym dostępem do GPU a koszmarem Re-captcha. Jak powiedziałem, może to być również zbieg okoliczności.

stason
źródło
4
Twoje oświadczenie: „W chwili pisania tego tekstu Google po prostu przekazuje tylko 5% GPU niektórym z nas, a pozostałym 100%. Kropka”. jest niepoprawne - Colab nigdy nie działał w ten sposób. Wszystkie zdiagnozowane przypadki, w których użytkownicy widzą mniej niż pełny zestaw dostępnej dla nich pamięci RAM GPU, sprowadzają się do innego procesu (uruchomionego przez tego samego użytkownika, być może w innym notebooku) wykorzystującego resztę pamięci RAM GPU.
Ami F
11
Przyszli czytelnicy: jeśli myślisz, że widzisz ten lub podobny symptom niedostępności pamięci RAM GPU, opcja „Zresetuj wszystkie środowiska wykonawcze” w menu Środowisko wykonawcze zapewni Ci nową maszynę wirtualną, gwarantując, że żadne przestarzałe procesy nie będą nadal przechowywać pamięci RAM GPU. Jeśli nadal widzisz ten objaw natychmiast po użyciu tej opcji menu, zgłoś błąd na github.com/googlecolab/colabtools/issues
Ami F
Wasza rzeczywistość wyraźnie różni się od rzeczywistości wielu innych, którzy nadal głosują za tym postem rok później po jego utworzeniu. Jest bardzo prawdopodobne, że niektórzy użytkownicy rzeczywiście napotykają to, co opisałeś, ale nie dotyczy to wszystkich. Więc nie jestem pewien, jak twoje oświadczenie pomaga tutaj. Poza tym, kiedy ktoś zadał dokładnie to pytanie w repozytorium, które poleciłeś, dostał odpowiedź BS i jego bilet został zamknięty: github.com/googlecolab/colabtools/issues/52
stason
2
Na wypadek, gdyby było niejasne: nie opisuję tego, co moim zdaniem implementacja opiera się na obserwacji zachowania systemu jako użytkownika. Opisuję, o czym bezpośrednio wiem, że implementacja jest. Wysłałem, mając nadzieję, że użytkownicy, którzy widzą mniej niż pełną dostępność, zgłaszają to jako problem (błąd użytkownika lub błąd systemowy), zamiast czytać niepoprawne stwierdzenia powyżej i zakładać, że wszystko działa zgodnie z przeznaczeniem.
Ami F
1
Nie, układy GPU nigdy nie były udostępniane, a przykład, z którym łączysz się, nie zawiera kłamstw (po prostu domysł i wyjaśnienie najczęstszej przyczyny zgłaszanego objawu).
Ami F
22

Ostatniej nocy uruchomiłem twój fragment i otrzymałem dokładnie to, co masz:

Gen RAM Free: 11.6 GB  | Proc size: 666.0 MB
GPU RAM Free: 566MB | Used: 10873MB | Util  95% | Total 11439MB

ale dzisiaj:

Gen RAM Free: 12.2 GB  I Proc size: 131.5 MB
GPU RAM Free: 11439MB | Used: 0MB | Util   0% | Total 11439MB

Myślę, że najbardziej prawdopodobnym powodem jest to, że procesory GPU są współdzielone między maszynami wirtualnymi, więc za każdym razem, gdy uruchamiasz ponownie środowisko wykonawcze, masz szansę zmienić GPU, a także istnieje prawdopodobieństwo, że przełączysz się na taki, który jest używany przez innych użytkowników.

AKTUALIZACJA: Okazuje się, że mogę normalnie korzystać z GPU, nawet gdy RAM GPU Wolny wynosi 504 MB, co uważałem za przyczynę ResourceExhaustedError, który dostałem ostatniej nocy.

Nguyễn Tài Long
źródło
1
Myślę, że połączyłem się ponownie prawdopodobnie 50 razy w ciągu kilku dni i na początku zawsze miałem takie samo 95% wykorzystanie. Tylko raz zobaczyłem 0%. We wszystkich tych próbach pojawiał się błąd cuda z pamięci, który zbliżał się do 100%.
stason
Co masz na myśli mówiąc o swojej aktualizacji? Czy nadal możesz uruchamiać rzeczy z 500 MB? Mam ten sam problem, dostajęRuntimeError: cuda runtime error (2) : out of memory at /pytorch/torch/lib/THC/generated/../THCTensorMathCompare.cuh:84
ivan_bilan
6

Jeśli uruchomisz komórkę, która właśnie zawiera
! Kill -9-1
, spowoduje to wyczyszczenie i ponowne uruchomienie całego stanu środowiska wykonawczego (w tym pamięci, systemu plików i GPU). Poczekaj 30-60 sekund i naciśnij przycisk CONNECT w prawym górnym rogu, aby ponownie nawiązać połączenie.

Ajaychhimpa1
źródło
2
dziękuję, ale twoja sugestia niczego nie zmienia. Nadal otrzymuję 5% pamięci RAM GPU.
stason
To nie pomaga. Po zabiciu i ponownym podłączeniu pamięć GPU nadal ma 500 MB z ~ 12 GB.
ivan_bilan
4

Wprowadzający w błąd opis ze strony Google. Myślę, że też byłem tym zbyt podekscytowany. Skonfigurowałem wszystko, załadowałem dane, a teraz nie mogę nic z tym zrobić, ponieważ do mojego notebooka przydzielono tylko 500 MB pamięci.

ivan_bilan
źródło
2

Znajdź pid Python3 i zabij pid. Zobacz poniższy obrazekwprowadź opis obrazu tutaj

Uwaga: zabij tylko pythona3 (pid = 130), a nie jupyter python (122).

Manivannan Murugavel
źródło
czy to pomoże w kwestii pamięci? czy nie zabijasz więc ucieczek wszystkich innych ludzi?
ivan_bilan,
to nie pomaga, mam ten sam problem:GPU RAM Free: 564MB
ivan_bilan Kwietnia
2

Zrestartuj jądro Jupyter IPython:

!pkill -9 -f ipykernel_launcher
mkczyk
źródło
1
blisko, ale nie ma cygara:GPU RAM Free: 564MB
ivan_bilan
prostszą metodą restartowania jądra jest po prostu kliknięcie Runtime | Zrestartuj środowisko wykonawcze ... lub skrótCMD/CTRL+M
Agile Bean
2

Nie jestem pewien, czy ta czarna lista jest prawdziwa! Jest raczej możliwe, że rdzenie są dzielone między użytkowników. Przeprowadziłem również test, a moje wyniki są następujące:

Wolna pamięć RAM generacji: 12,9 GB | Rozmiar procesu: 142,8 MB RAM GPU Wolny: 11441 MB | Używany: 0MB | Utylizacja 0% | Razem 11441 MB

Wygląda na to, że mam również pełny rdzeń. Jednak uruchomiłem go kilka razy i otrzymałem ten sam wynik. Może powtórzę to sprawdzenie kilka razy w ciągu dnia, aby sprawdzić, czy jest jakaś zmiana.

Kregnach
źródło
2

po prostu daj ciężkie zadanie Google Colab, poprosi nas o zmianę na 25 GB pamięci RAM.

wprowadź opis obrazu tutaj

przykład uruchom ten kod dwukrotnie:

import numpy as np
from keras.layers import Conv2D, MaxPooling2D, AveragePooling2D
from keras.layers import Dropout, Flatten, Dense
from keras.models import Sequential
from keras.layers.advanced_activations import LeakyReLU
from keras.datasets import cifar10
(train_features, train_labels), (test_features, test_labels) = cifar10.load_data()
model = Sequential()

model.add(Conv2D(filters=16, kernel_size=(2, 2), padding="same", activation="relu", input_shape=(train_features.shape[1:])))
model.add(MaxPooling2D(pool_size=(2, 2), padding='same'))

model.add(Conv2D(filters=32, kernel_size=(3, 3), padding="same", activation="relu"))
model.add(MaxPooling2D(pool_size=(2, 2), padding='same'))

model.add(Conv2D(filters=64, kernel_size=(4, 4), padding="same", activation="relu"))
model.add(MaxPooling2D(pool_size=(2, 2), padding='same'))

model.add(Flatten())

model.add(Dense(25600, activation="relu"))
model.add(Dense(25600, activation="relu"))
model.add(Dense(25600, activation="relu"))
model.add(Dense(25600, activation="relu"))
model.add(Dense(10, activation="softmax"))

model.compile(optimizer='adam', loss='sparse_categorical_crossentropy', metrics=['accuracy'])

model.fit(train_features, train_labels, validation_split=0.2, epochs=10, batch_size=128, verbose=1)

następnie kliknij, aby uzyskać więcej pamięci RAM :) wprowadź opis obrazu tutaj wprowadź opis obrazu tutaj

wprowadź opis obrazu tutaj

Jainil Patel
źródło
Mogę to potwierdzić. Miałem zbiór danych na 15 gigów, składający się głównie z obrazów HD (mój dysk ma 30 gigów zamiast 15 gigów) i uruchomiłem kod, aby zmienić rozmiar zestawu danych obrazu do 224,224,3 i zostałem przełączony na wysoki czas pracy RAM. Potem, kiedy zacząłem trenować, użycie pamięci RAM wzrosło do 31,88 gigów.
Anshuman Kumar
Ale chciałbym dodać, że po zakończeniu tej pracy nie mogłem uzyskać dostępu do innego GPU / TPU przez ostatnie 24 godziny. Możliwe, że znalazłem się na czarnej liście.
Anshuman Kumar
@AnshumanKumar, daj duże obciążenie na początku tylko w przeciwnym razie przy zmianie konfiguracji stracisz wcześniej wykonaną pracę, która w pamięci RAM. Nie korzystałem z wysokiej konfiguracji przez 24 godziny, więc nie wiem o czarnej liście.
Jainil Patel
Tak, tak się stało ze mną. Jednak praca została wykonana.
Anshuman Kumar
1

Myślę, że mamy otwartych wiele zeszytów. Samo zamknięcie go nie zatrzymuje procesu. Nie wymyśliłem, jak to zatrzymać. Ale użyłem top, aby znaleźć PID pythona3, który działał najdłużej i zużywał większość pamięci, i go zabiłem. Teraz wszystko wróciło do normy.

Ritwik G
źródło