我使用 R 进行了大量统计分析，并大量使用 AWS 上的大型多核实例。主要用于超参数搜索、交叉验证和引导。
假设我有一个带有核心的实例c，以及一个带有副本的作业，这些副本一次r >= c外包给核心。c现在，由于系统进程（例如我的 ssh 客户端正在运行），除了我的复制 htop之外还有作业正在运行。c
这意味着，据我了解操作系统的工作原理，有一些进程正在关闭我的作业，以便htop（以及其他任何东西）可以访问处理器。在让这些不同的过程在阳光下暴露一段时间后，我的工作又恢复了。
当我看时htop，我看到很多红色与绿色混合在一起。绿色是我的工作，红色是为实现我的工作而完成的背景材料，这样说准确吗？
直觉上，这种洗牌似乎不是最优的。所以这是我的直接问题：如果我有权访问c核心，我是否应该将复制作业分配给所有c核心，或者也许c-1什么？
我还想象有很多关于如何将计算资源分配给我不理解且掩盖的作业的细节。让我的所有工作都进入c-1核心并且所有系统进程都进入核心会涉及什么cth？这会让我的所有 htop 都变成绿色吗，除了一个栏之外？这有什么意义吗？
我想我可以做基准测试实验，但这对于巨大的实例和数据集来说会很困难，而且考虑到有多少东西是特定于应用程序的，我不确定我会学到什么。所以我想更好地了解事情是如何运作的。
答案1
如果不进行实验，很难知道对特定应用程序的确切影响，但一般的经验法则是，稍微超出内核数量是有益的（例如，大多数编译指南建议使用内核/线程数 + 调用 make） 1)，但由于额外的开销，大量超过它可能会适得其反。这样做的原因是，如果一个（或几个）任务正在休眠等待 I/O 或计时器或其他任务，其他线程仍然可以继续进行。
工作改组（操作系统调度）发生在所有现代操作系统上，我们应该与之合作，而不是与之对抗。如果似乎存在一些不相关的竞争，您可以降低流程的良好级别，但在专用的 AWS 实例上......很难想象需要这样做。