因此,我简单查看了 cgroups 和 numactl,但根据我找到的信息,它们似乎都不是我需要的。
我们使用一款名为“fast-X”的软件,以便我们的用户通过网络登录到他们的图形会话。它似乎有一个严重的缺陷,即当它在超过 120 个核心的系统上运行时,性能会下降。问题是,我们的大型数字运算机器是 240 个核心的系统。
因此,我需要找到一种可以动态地说“哦,有人正在启动 fastx 进程,将其限制到这 X 个核心”的方法,因为 numactl 和 cgroups 似乎依赖于您使用它们启动该进程,或者在进程启动后强行移动该进程,这些对我来说并不真正起作用...
对于不熟悉 fastx 的人来说(可能有很多),它基本上是一个远程桌面/X11 客户端,可以保存用户会话,并且通常(在 120 核或更少的系统上)具有出色的性能。因此,用户将通过 Windows 应用程序连接到服务器,然后该应用程序将自动启动他们的会话,这就是为什么我需要在服务器端自动限制它的东西,而不是必须强制启动它的东西。
到目前为止我还没有发现任何东西,任何想法都将不胜感激。
答案1
大多数集群调度程序/资源管理器还允许将任务绑定到特定的 CPU 或核心。 泥浆和摩押是 HPC 集群系统上非常常用的资源管理器,并通过标准 CPU 以及 GPU、协处理器和其他计算加速器等额外的计算资源提供此功能。
如果可以将队列保持足够小,那么理论上,用户登录可以自动将交互式作业提交到队列,然后以用户登录控制台的形式在 fastx 中启动结果。甚至可以设置一种机制,将用户限制在某些 CPU 组中,以确保不允许任何单个用户使用过多的资源。但是,如果队列变得太大,用户将不得不等待资源可用。
虽然我实际上还没有见过以这种方式使用的资源管理器,但如果资源管理器/调度程序允许启动交互式作业,理论上应该是可行的,这是大多数现代调度程序都具有的功能。如果没有其他方法可行,这是一个理论上可行的选择。如果任何特定进程使用的核心数量需要能够在进程的整个生命周期内变化,则可能还有其他更合适的替代方案。
虽然不完全相似,但有一个调度示例NIH Biowulf 集群上的 Fastx。他们似乎使用 PBS 批处理脚本通过调度程序启动作业,因此某些概念可能可重复使用。
康奈尔大学的这个例子似乎还展示了 Fastx 与 PBS 的用法,所以这似乎是以前做过的事情。不过,这个例子确实有点过时了。