Google Colaboratory：其GPU信息误导了用户（对某些用户仅有5％的可用RAM）

Question

Google Colaboratory：其GPU信息误导了用户（对某些用户仅有5％的可用RAM）

pythonmachine-learninggpuramgoogle-colaboratory

133

更新: 这个问题与Google Colab的“笔记本设置:硬件加速器:GPU”有关。这个问题是在“TPU”选项添加之前编写的。

看到多个激动人心的消息，称Google Colaboratory提供免费的Tesla K80 GPU，我尝试在上面运行fast.ai课程，但它从未完成——很快就会耗尽内存。我开始调查为什么。

底线是，“免费的Tesla K80”并不是对所有人都是“免费”的——对于一些人来说，只有一小部分是“免费的”。

我从加拿大西海岸连接到Google Colab，我只获得了0.5GB的GPU RAM，而其他用户可以访问11GB的GPU RAM。

显然，0.5GB的GPU RAM对于大多数ML/DL工作是不足够的。

如果您不确定自己获得了什么，这里有一个小调试函数（仅适用于笔记本的GPU设置）：

# 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()

在运行任何其他代码之前，在jupyter笔记本中执行它会给我：

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

获得完整卡片访问权限的幸运用户将看到：

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

你从GPUtil中借鉴的GPU RAM可用性计算中是否存在任何缺陷？

如果您在Google Colab笔记本上运行此代码，能否确认您获得类似的结果？

如果我的计算是正确的，有没有办法在免费的计算机上获取更多的GPU RAM？

更新：我不确定为什么我们中的一些人只能获得其他用户的1/20。例如，帮助我调试的人来自印度，他可以获得全部内容！

注意：请不要再发送关于如何杀死可能被卡住/失控/并行的笔记本电脑的建议。无论如何，如果您和我处于同样的困境，并运行调试代码，则仍将获得总共5％的GPU RAM（截至此更新仍然是这样）。

- stason

有什么解决办法吗？为什么执行!cat /proc/meminfo时会得到不同的结果？ - figs_and_nuts

3

试试IBM开源数据科学工具(cognitiveclass.ai)，它们还提供带Jupyter Notebooks的免费GPU。 - A Q

1

我已将此问题回滚到实际上有一个“问题”的状态。如果您已经进行了更多的研究并找到了答案，适当的地方是在答案框中。更新问题以提供解决方案是不正确的。 - Chris Hayes

你尝试过设置TensorFlow会话配置吗？例如，gpu_options=tf.GPUOptions(per_process_gpu_memory_fraction=1)和sess = tf.Session(config=tf.ConfigProto(gpu_options=gpu_options)。 - user3731622

谢谢你，但这个问题绝对与TF无关。我不确定为什么你认为它与TF有关。 - stason

显示剩余5条评论

9个回答

24

昨晚我运行了你的片段，得到了与你完全相同的结果：

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

但今天：

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

我认为最可能的原因是GPU被多个虚拟机共享，因此每次重新启动运行时，您有机会切换GPU，并且还有可能切换到其他用户正在使用的GPU。

更新：事实证明，即使GPU RAM Free为504 MB（我认为这是昨晚我遇到的ResourceExhaustedError的原因），我仍然可以正常使用GPU。

- Nguyễn Tài Long

1

我觉得在几天的时间里，我大概重新连接了50次，一开始总是得到相同的95%使用情况。只有一次看到是0%。在所有尝试中，当接近100%时，我都会遇到cuda内存不足错误。 - stason

你的更新是什么意思？你还能用500Mb运行程序吗？我也有同样的问题，出现了“RuntimeError: cuda runtime error (2) : out of memory at /pytorch/torch/lib/THC/generated/../THCTensorMathCompare.cuh:84”错误。 - Ivan Bilan

7

如果你执行一个只包含!kill -9 -1的单元格，那么将会导致运行时的所有状态（包括内存、文件系统和GPU）被清除并重启。等待30-60秒后，点击右上角的连接按钮重新连接。

- Ajaychhimpa1

2

谢谢你的建议，但它并没有改变任何事情。我仍然使用了5%的GPU内存。 - stason

这并没有帮助。在杀死和重新连接之后，GPU内存仍然是12GB左右的500MB。 - Ivan Bilan

3

重新启动 Jupyter IPython 内核：

!pkill -9 -f ipykernel_launcher

- mkczyk

1

差强人意：GPU RAM 可用空间：564MB - Ivan Bilan

作为重新启动内核的更简单的方法，您可以只需单击“运行时”|“重新启动运行时”...或快捷键CMD/CTRL+M。 - Agile Bean

2

找到Python3的进程ID并杀死该进程。请参见下面的图片

注：仅杀死Python3（pid=130），不要杀死jupyter python(122)。

- Manivannan Murugavel

这会有助于内存问题吗？那你不是要杀死所有其他人的运行吗？ - Ivan Bilan

这并没有帮助，仍然遇到了同样的问题：“GPU RAM Free: 564MB”。 - Ivan Bilan

2

我不确定这个黑名单是否正确！更有可能的是，核心被用户共享。我也进行了测试，我的结果如下：

最初的回答：

Gen RAM Free: 12.9 GB  | Proc size: 142.8 MB
GPU RAM Free: 11441MB | Used: 0MB | Util   0% | Total 11441MB

看起来我的核心也已经满了。不过我运行了几次，得到了相同的结果。也许我会在一天之内重复这个检查几次，看看是否有任何变化。

Original Answer翻译成"最初的回答"

- Kregnach

2

只需将繁重的任务交给Google Colab，它会要求我们切换到25 GB的RAM。

示例：运行此代码两次：

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)

然后点击“获取更多内存” :)

- Jainil Patel

我可以确认这一点。我有一个15GB的数据集，其中大部分是高清图片（我的驱动器有30GB而不是15GB），然后我运行了代码将图像数据集调整为224,224,3，并切换到高RAM运行时。然后当我开始训练时，RAM使用量增加到31.88GB。 - Anshuman Kumar

但我想补充一点，自从完成那项工作后，我在过去的24小时内无法访问另一个GPU/TPU。可能我已被列入黑名单。 - Anshuman Kumar

@AnshumanKumar，在开始时提供高负载，否则在更改配置时，您将失去先前在内存中完成的工作。我没有连续使用高配置24小时，所以我不知道黑名单方面的情况。 - Jainil Patel

是的，这种情况也发生在我身上。不过工作还是完成了。 - Anshuman Kumar

1

我认为如果我们打开了多个笔记本，仅仅关闭它并不能真正停止进程。我还没有找到如何停止它的方法。但是我使用 top 命令找到了运行时间最长、占用最多内存的 python3 进程的 PID 并将其杀掉。现在一切都恢复正常了。

- Ritwik G

-1

Google Colab的资源分配是动态的，基于用户过去的使用情况。假设一个用户最近使用了更多资源，而一个不经常使用Colab的新用户将在资源分配上被相对优先考虑。

因此，为了充分利用Colab，关闭所有Colab标签和其他活动会话，重置您想要使用的运行时。您肯定会获得更好的GPU分配。

- Ankit Veer Singh

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- stason · Accepted Answer

为了避免再次提出无效建议，例如在本主题上建议执行!kill -9 -1，让我们关闭这个主题：

答案很简单：

截至本篇文章编写时，Google仅将5％的GPU分配给我们中的一些人，而将100％分配给其他人。完结撒花。

2019年12月更新：问题仍然存在-此问题的赞继续不断。

2019年3月更新：一年后，一位名为@AmiF的Google员工对问题的状态进行了评论，指出问题不存在，任何似乎存在此问题的人都需要简单地重置运行时以恢复内存。然而，赞数仍在增加，这说明问题仍然存在，尽管@AmiF提出了相反的建议。

2018年12月更新：我有一个理论，即当其机器人检测到非标准行为时，Google可能会拥有某些帐户或浏览器指纹的黑名单。这可能是纯属巧合，但我在很长一段时间内在任何需要它的网站上都对Google Re-captcha有问题，我必须经过数十个难题才能通过，通常需要花费我10分钟以上的时间。这种情况持续了很多个月。突然间，从本月开始，我根本不需要解决任何问题，任何Google Re-captcha都可以通过一次鼠标单击来解决，就像将近一年前那样。

我为什么要讲这个故事呢？因为在同一时间，我在 Colab 上得到了 100% 的 GPU RAM。所以我的猜测是，如果你被Google理论上的黑名单所列，那么你就不能信任免费获得大量资源。我想知道是否有人发现有限制的GPU访问和Re-captcha噩梦之间的相似之处。正如我所说，这也可能完全是巧合。