Open momomobinx opened 3 years ago
nvidia-smi 显示的内存好像不是真实占用的。之前我也遇到这个问题了。TF2.0 默认情况下会申请所有的剩余的显存,但不一定会用到。后来设置了动态申请,用多少申请多少。这时候,如果真实使用的内存超过 gpushare 分配的内存,cgroup 会将进程杀掉。
nvidia-smi 显示的内存好像不是真实占用的。之前我也遇到这个问题了。TF2.0 默认情况下会申请所有的剩余的显存,但不一定会用到。后来设置了动态申请,用多少申请多少。这时候,如果真实使用的内存超过 gpushare 分配的内存,cgroup 会将进程杀掉。
按照官方示例上展示的是,gpushare分配 3G 然后 在 tf2.0 中使用 nvidia-smi 看到的就是 3G 然后使用也不会超过 这个 3G,然后在宿主机上查看 (假设宿主机是10G) 应该也是只占用 3G 总的 10G
nvidia-smi 显示的内存好像不是真实占用的。之前我也遇到这个问题了。TF2.0 默认情况下会申请所有的剩余的显存,但不一定会用到。后来设置了动态申请,用多少申请多少。这时候,如果真实使用的内存超过 gpushare 分配的内存,cgroup 会将进程杀掉。
参考这个实例 运行GPU共享实例
gpushare scheduler负责按照显存维度为单位,在集群中去调度作业,也就是找到哪个node上的哪块GPU卡还能提供作业所需显存大小。作业pod被调度到node上,会绑定合适的GPU卡到容器内。此时调度就完成了。 如果需要在容器内限制进程实际使用的显存量,还需要配合GPU隔离,这个就不在调度器的能力里了。 实现node上单GPU卡显存隔离的方案可以参考阿里云的cGPU,或Nivdia的MPS,或Nvidia A100的MIG等等
阿里云的cGPU
你好,那我想知道yaml文件中的配置文件起什么作用呢?
实际使用没有被限制住
gpushare scheduler负责按照显存维度为单位,在集群中去调度作业,也就是找到哪个node上的哪块GPU卡还能提供作业所需显存大小。作业pod被调度到node上,会绑定合适的GPU卡到容器内。此时调度就完成了。 如果需要在容器内限制进程实际使用的显存量,还需要配合GPU隔离,这个就不在调度器的能力里了。 实现node上单GPU卡显存隔离的方案可以参考阿里云的cGPU,或Nivdia的MPS,或Nvidia A100的MIG等等
阿里cGPU方案有开源吗?
已收到,谢谢!
已收到您的邮件,我将及时查看并回复,谢谢 王鑫
这个项目应该只是利用K8s的设备插件机制上报GPU资源,包括卡数和显存,再利用k8s的调度扩展机制自定义个调度器调度到某个node节点的某个卡上而已。至于限制那是类似cGroups机制实现。应该是kernel+GPu Driver层面去优雅的实现。或者用户态的CUDA劫持去实现。个人还是倾向于前者。或者Nvidia的MIG方案。但MIG支持显卡种类有限。
我在自己的服务器上部署了k8s 单节点,然后按照教程安装配置了 阿里gpu 插件 ,安装部署kubeflow ,在里面创建notebook 配置 8G 显存,但是在实际使用中还是会占用到一张显卡的几乎全部内存。还是是说在没有其他任务的情况下就会直接占满使用?
nvidia-smi 查看信息
kubectl-inspect-gpushare 查看信息
kubectl describe pod luk-test-gpu-notebook-0 -nkubeflow-user-example-com