GPU的程序kill后未释放内存

最新推荐文章于 2025-03-29 23:21:36 发布

转载最新推荐文章于 2025-03-29 23:21:36 发布 · 395 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/u/2286010/blog/3050670

文章标签：

#运维 #shell

博客介绍了GPU程序管理及僵尸进程处理方法。先关闭ssh或shell窗口重新登录，接着用fuser -v /dev/nvidia*查看运行在gpu上的所有程序，最后kill掉连号的僵尸进程。

部署运行你感兴趣的模型镜像

1.先关闭ssh（或者shell）窗口，退出重新登录

2.查看运行在gpu上的所有程序：

fuser -v /dev/nvidia*

3.kill掉所有（连号的）僵尸进程

转载于:https://my.oschina.net/u/2286010/blog/3050670

您可能感兴趣的与本文相关的镜像

Llama Factory

模型微调

LLama-Factory

LLaMA Factory 是一个简单易用且高效的大型语言模型（Large Language Model）训练与微调平台。通过 LLaMA Factory，可以在无需编写任何代码的前提下，在本地完成上百种预训练模型的微调

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

chenkui5098

关注关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

【Linux】程序已经运行完了，但是占着GPU，没有释放内存怎么办——kill -9 PID

weixin_44502754的博客

05-21

1719

【Linux】程序已经运行完了，但是占着GPU，没有释放内存怎么办——kill -9 PID

Paddle下训练模型，训练程序停止后GPU未正常释放解决

l13022736018的博客

06-30

4557

Paddle下训练模型，训练程序停止后GPU未正常释放解决摘要使用PaddleDetection 训练模型，由于程序报错，训练程序停止，查看GPU的使用情况发现使用的显卡无对应运行的程序，但显卡的内存并未正常释放。本博文将对这个问题记录一下解决方案，防止再出现类似的问题。查看GPU的使用情况运行 ...

参与评论您还未登录，请先登录后发表或查看评论

方法-进程已经杀死但是显存还未释放怎么办(ubuntu)

zwhdldz的博客

11-30

1473

训练程序ctrl+c后,依然显示显存占用。##查看后台的训练进程。

nvidia-smi GPU的程序kill后未释放显存

乱七八糟的笔记

06-03

5683

tensorflow数据并行，中途中断了，毕竟头一次自己的程序并行跑，很有可能就出错。结果某次出错，GPU并未释放内存; 1 fuser -v /dev/nvidia* 然后需要逐个杀死，注意使用管理员身份杀死之后，世界清净了： ...

【ubuntu】GPU进程kill后，显存未释放（杀死僵尸进程）

luckynote

10-08

8125

通过以下命令查看僵尸进程 sudo fuser -v /dev/nvidia* 然后通过以下命令逐一kill僵尸进程 sudo kill -9 进程

服务器kill掉的进程为什么还占内存

薰珞婷紫小亭子的博客

11-17

2090

服务器kill掉的进程为什么还占内存

解决pytorch GPU 计算过程中出现内存耗尽的问题

09-18

在循环中，如果我们将这样的变量作为累加器，如上述例子中的`total_loss += loss`，就会导致GPU内存持续增长，因为`loss`变量在每次迭代后都会保留其梯度信息。为解决这个问题，我们可以将累加操作改为`total_loss +...

java检查gpu占用_解决GPU显存未释放问题

weixin_33668386的博客

02-24

982

前言今早我想用多块GPU测试模型，于是就用了PyTorch里的torch.nn.parallel.DistributedDataParallel来支持用多块GPU的同时使用(下面简称其为Dist)。程序运行时，由于程序中其他部分的代码(与Dist无关的代码)出现了错误，导致程序退出。这次使用Dist时没有考虑和处理这种程序崩溃的情况，因此在程序退出前没有用Dist关闭生成的所有进程，最终导致本次进...

实验室服务器使用指南06：kill-9杀不死进程及无进程占用GPU但显存占用大

qq_41876456的博客

12-21

1950

参考资料杀掉kill -9杀不死的进程 nvidia-smi无进程占用GPU但GPU显存被占用很多 1.最初是想杀掉8208这个进程，然后很自然地就想kill -9 8208 2.用了kill -9这个命令之后就发现Process name没了，但还是占用内存 3.然后使用cat /proc/8208/status这个命令找到8208这个pid号的父目录ppid 8207,再把父目录杀掉 4.然后8208这个pid果然被杀掉了，但是仍然占用内存？？？ 5.于是使用fuser -v /dev/nv

Jumpserver celery 僵尸进程导致内存不释放的问题

大雪冬至的博客

10-25

1362

Jumpserver celery 僵尸进程导致内存不释放的问题现象： Jumpserver 启动一段时间后，会出现僵尸进程，观察后发现是 celery 的某些进程。 [root@web00-and-backend00 ~]# ps -A -ostat,ppid,pid,cmd |grep -e '^[Zz]' Z 27985 8114 [celery] <defunct> Z 27984 8908 [celery] <defunct> Z 27986

进程Kill杀死后GPU显存没有释放仍然被占用，怎么杀死僵尸进程

热门推荐

ture_dream的博客

10-04

2万+

first of all: input : nvidia-smi hen you can see: t 杀死进程命令：kill -9 PID the PID should be number in the chart ,such as 5882 最后重新运行试验，就可以开始跑了

Ubuntu kill空占GPU显存的进程

darknight

08-16

4376

有的时候，明明自己没有跑任何程序，但是GPU显存的一部分却显示被占用，经过下列三步可以kill空占GPU显存的进程。 1.首先安装fuser sudo apt-get install psmisc 2.查看占用GPU显存的进程在使用nvidia-smi或者gpustat指令都找不到占用显存进程的情况下，使用下述指令查询 fuser -v /dev/nvidia* 3.kill空占显存的进程 ...

详解 Linux 网络命令及进程管理：深入理解wpa_supplicant、udhcpc 和 killall

weixin_52734695的博客

08-29

1227

wpa_supplicant 是一个用于 Linux 系统中管理无线网络连接的守护进程。它支持多种加密协议，如 WPA、WPA2，并与操作系统的网络堆栈交互，确保设备能够安全、稳定地连接到无线网络。

Ubuntu系统kill后，显示看不到进程，但GPU显存仍被占用问题

qq_35608277的博客

09-18

1625

Ubuntu系统有时候会出现GPU显存显示占满，但是使用nvidia-smi命令 kill python 后仍然显示内存占用。

kill -9都杀不掉的进程

xumingrencai

03-20

457

转载自：http://blog.youkuaiyun.com/bat603/article/details/1717024 kill -9发送SIGKILL信号将其终止，但是以下两种情况不起作用： a、该进程处于"Zombie"状态（使用ps命令返回defunct的进程）。此时进程已经释放所有资源，但还未得到其父进程的确认。"Zombie"进程要等到下次重启时才会消失，但它的存在不会影响系统性能。 ...

linux释放GPU

03-26

### 如何在 Linux 系统中释放 GPU 资源当程序运行结束后未正常释放 GPU 资源时，可以采取以下措施来手动释放这些资源。 #### 查看当前 GPU 使用情况通过 `nvidia-smi` 命令查看当前 GPU 的使用状态以及占用它的进程 ID (PID)[^1]。 ```bash nvidia-smi ``` 如果能够找到具体的 PID，则可以直接杀死该进程以释放 GPU 显存。 #### 杀死特定进程对于已知的 PID，可以通过发送信号强制终止对应进程： ```bash kill -9 <PID> ``` 此命令会立即停止指定的进程并尝试释放其持有的 GPU 资源。 #### 处理无可见 PID 的显存占用有时即使 GPU 存在显存占用，但在 `nvidia-smi` 中却看不到任何关联的进程。此时可采用如下方式解决： ##### 方法一：利用 `fuser` 工具扫描设备文件执行以下命令查找正在使用的 NVIDIA 设备及其对应的进程号，并结束它们： ```bash sudo fuser -v /dev/nvidia* ``` 上述指令不仅显示哪些进程正访问 `/dev/nvidia*` 文件，还会提供更多信息以便确认目标进程身份。随后可根据反馈结果逐一清除干扰项： ```bash sudo kill -9 $(sudo fuser -k /dev/nvidia*) ``` 这种方法适用于那些隐藏于常规工具检测之外但仍实际持有硬件控制权的情况[^2]。 ##### 方法二：重启 X Server 或整个系统服务作为最后手段之一，在不影响整体服务器稳定性的前提下考虑重新启动图形界面或者计算机本身的服务链路也可能有效果；不过这通常只应在其他所有选项均失败之后才实施。 #### 自动化管理 Tensorflow/GPU 配置为了避免未来再次遇到类似问题，建议调整 TensorFlow 应用中的参数设置使其更加合理高效地分配和回收计算资源。例如启用动态增长功能减少不必要的锁定行为： ```python import tensorflow as tf gpus = tf.config.experimental.list_physical_devices('GPU') if gpus: try: # 设置GPU按需增长 for gpu in gpus: tf.config.experimental.set_memory_growth(gpu, True) except RuntimeError as e: print(e) ``` 这样做的好处在于可以让框架内部更灵活处理物理内存请求从而降低外部干预需求频率[^3]。另外值得注意的是某些特殊场景可能还需要额外配置环境变量比如 CUDA_VISIBLE_DEVICES 控制可用范围进一步优化多卡协作模式下的表现效果[^4]。