在服务器中用一个好的“前缀”替换 Julia|R|Python 可执行文件是否有意义?

在服务器中用一个好的“前缀”替换 Julia|R|Python 可执行文件是否有意义?

我在我的实验室中管理一个计算服务器(单 CPU),用户使用各种界面(RStudio 服务器、JupyterHub/VsCode、命令行......)在 R|Python|Julia 中编写脚本并运行程序。

为了确保它们的负载不会影响系统程序,并且每个程序不会阻塞其他程序的所有工作,用 来包装例如 会很有用julia,对和 也nice -n 10 juliaorig一样,还是说没用?RPython

编辑:对我来说,最佳方案是在用户(而不是进程)之间平等分配资源,例如,拥有 12 个正在运行的线程的用户 A 获得的 CPU 时间与拥有 6 个线程的用户 B 和运行单个线程的用户 C 相同……次优方案是限制用户的核心数量,或者“欺骗”操作系统将此(较低的)核心数量传达给询问可用核心数量的应用程序。这样做的好处是,如果用户确实需要,他仍然可以手动将脚本的线程数设置为更高的级别。

答案1

nice是相对优先级。仅当某些程序的优先级高于其他程序时,更改它才有意义。

但如果全部用户程序的优先级被重新设置为 10,最终结果是所有用户的优先级又都一样了,就像以前一样(所有用户的优先级都一样,都是 20)。你唯一取得的成果就是让所有用户的优先级都低于系统服务和其他工具(它们仍然为 20),所以现在你的apt upgrade工作压垮了所有人。

(大多数系统服务不需要比用户更高的优先级。对于少数需要的优先级,应提高服务的优先级,而不是降低用户的优先级。)

具有同等优先级(无论是 10 还是 20),一个用户程序已经不应阻塞其他进程。内核的进程调度程序应该或多或少公平地分配 CPU 时间,磁盘 I/O 也是如此。唯一的问题是,拥有更多进程的用户将比拥有较少进程的用户获得更多的 CPU 时间,但这可能不是你用你的建议可以解决的问题。

据我所知,将每个用户的进程放在单独的控制群组将在 cgroup 级别平衡资源。这通常是基于 systemd 的系统上的默认设置,尽管您可能仍需要启用 CPU 核算并设置 CPU 权重user-.slice。(您通过user-.slice.d/*.conf(是的,-.)执行的所有设置将被每个user-XXX.slicecgroup 继承。)

(Cgroups 更常用于容器;您可能还会看到有关每个容器公平 CPU 共享的资源,这应该以相同的方式应用于每个用户。)


“单 CPU” 没问题,只要它是多核的;每个核心几乎都是一个独立的 CPU。但如果它也是单核的,那么就该升级了。(它是 VM 还是 Pentium 3?)

相关内容