watch -n 1 nvidia-smi使cuda c编写的程序变慢

  • 3 replies
  • 159 views
watch -n 1 nvidia-smi使cuda c编写的程序变慢
« 于: 十月 04, 2018, 02:47:20 pm »
 本帖最后由 muzidianli 于 2018-10-4 14:50 编辑

一边运行cuda c程序处理一批图片(逐张循环处理),一边打开watch -n 1 nvidia-smi查看gpu状态,发现程序在执行中有一定概率会在某张图片处理开始的第一个cudaMalloc处卡住,有时30秒左右,有时1分钟左右,当前图片通过卡住函数之后的剩下cudaMalloc等函数运行时间均还算正常,下一张图片是否会有卡主问题未找到规律。关闭nvidia-smi,一切正常。不知哪位[名词2]遇到过类似的情况,不知是否可以避免这个干扰的发生

(无标题)
« 回复 #1 于: 十月 08, 2018, 12:28:54 pm »
首先说, 在我使用N卡这么多年, 没有见到这种现象,也从未听说有人反馈过nvidia-smi或者NVML(后者是前者所调用的库)会导致这种现象, 甚至“卡上30多秒到1分钟”。

此外, 正常我们常看到是nvidia-smi dmon, 不过这个不重要。哪种都行。

根据你的描述, 如果会在“第一次cudaMalloc”卡住,还往往代表了你程序结构上的存在的问题:
(1)例如muzidianli是否尝试某张图片重新起一个进程,如果是,请不要这样做。
(2)例如muzidianli如果规避了(1),是否注意你并不需要反复的cudaMalloc(以及cudaFree)的, 这完全没有必要。
(3)在Linux下的话, 你是否注意了设定驱动驻留?(例如nvidia-smi -pm 1), 否则每次启动进程都会有额外开销。

等等吧。

总之,我不认为这是NVML或者nvidia-smi会干扰正常程序。我建议你从我怀疑的其他方面进行检查。

(无标题)
« 回复 #2 于: 十月 12, 2018, 02:12:00 pm »
 本帖最后由 muzidianli 于 2018-10-12 14:42 编辑

首先说, 在我使用N卡这么多年, 没有见到这种现象,也从未听说有人反馈过nvidia-smi或者NVML(后者是前者 ...

首先感谢版主的答复
就版主的几点建议,我尝试解释一下
1)我所说的情况发生在测试时,我把c++和cuda c混合编写的代码编译成so文件,用python调用并循环处理图片,这里没有用多线程/进程。在python代码启动时,so就加载上了,然后是在每处理一张图片时,调用so中的函数新建对应的对象,处理图片,最后析构对象。。。。个人认为应该不会有多进程的问题吧,但是以后部署服务的时候,这个可能是个问题
2)现在之所以每次cudamalloc,是因为每次处理的图片大小都不一样,需要的显存也随之不太一样,不知道是否仍然可以规避,不用每次malloc
3)这个,我俩互相都不认识对方,我再研究研究

另外,nvidia-smi dmon这个刚知道,多谢指点,好用!

最后,再次感谢版主的文字

(无标题)
« 回复 #3 于: 十月 22, 2018, 11:08:27 pm »
首先感谢版主的答复
就版主的几点建议,我尝试解释一下
1)我所说的情况发生在测试时,我把c++和cuda c ...

图片不一样大,你试试按最大的分配,按实际大小来使用,避免重复分配和回收显存。