在一台机器（AWS m5.large）上仅运行nice后台处理作业（即不存在 Web/DB/etc 服务器），持续让 CPU 以 100% 运行有什么缺点吗？
我理解，运行系统会消耗 100% 的可用资源记忆不是一个好主意。如果没有交换，系统在内存不足时会直接终止进程。即使有交换，系统也会开始交换页面，这会大大降低整个系统的速度。
但是，我的理解是，如果一个系统的niceCPU 使用率为 100%，那么运行 'd 进程时，系统将不会出现明显的减速。这是正确的吗？
或者，尝试配置后台进程以使系统保持在 60% - 90% 的 CPU 使用率范围内是否更好？
答案1
只要系统按您的需要运行，并且对登录和更改做出响应，那么运行 100% CPU 是没有问题的，这就是它的用途。Nice 只会更改进程的相对优先级。
在 AWS 中，如果您使用了 100% 的 CPU，请避免使用 T 系列实例，因为它们会提供部分 CPU。在 CPU 分配方面，获得 M（通用）/ C（计算密集型）/ 其他系列 VM 以获得已承诺的 CPU 比使用“T2 / T3 无限制”更便宜。
针对一条评论，AWS（我认为还有其他领先的云提供商）没有针对 CPU 的“公平使用”政策，这些政策往往来自低端提供商或共享主机。如果您为核心付费，则可以 100% 使用该核心。如果您的实例未得到充分利用，AWS Trusted Advisor 服务会推荐较小的实例来帮助您节省资金。
在本地，您显然可以做任何您想做的事情。这个答案是常见情况，并且特别适用于云，特别是 AWS。
答案2
无论你nice是否运行，CPU 占用率达到 100% 都意味着你无法以尽可能快的速度处理任务，即使你有更多的 CPU 可用。整个系统确实会变慢。它对nice你唯一的作用就是让你指出哪些进程具有更高或更低的优先级，哪些进程应该占用更多或更少的已经有限的 CPU。
如果您的作业比您预期的要慢，那么唯一能产生重大影响的就是为它们提供更多 CPU。如果您从其他作业中获取 CPU，那么这些作业就会变慢。如果您升级 CPU，那么一切都会运行得更快。当然，由于它是 EC2，您也可以添加更多实例。
答案3
CPU 运行 100% 是没有问题的。
即使在极少数情况下，您的特定硬件出现冷却问题导致过热，但由于这是 AWS 服务器，所以这也是亚马逊的问题，而不是您的问题（请放心，他们在定价模型中已考虑到这一点）
如果它不做那项工作，它就会闲置，所以如果你需要完成一项工作，最好让它去做。你不想人为地限制它。
主要缺点是持续以 100% 的速度使用 CPU 需要更多电量。但你想完成这项任务，对吧？¹
（¹请注意，在某些情况下，例如比特币挖矿，电力成本高于挖出的比特币的价值）
其次，如果系统 CPU 100% 地用于执行一些不太重要的任务（例如处理 SETI 数据包），则可能会发生更重要的任务（例如所有者的交互请求），但计算机无法及时注意到它，因为它正忙于处理这些数据包。通过优先处理那些不太重要的任务可以解决这个问题。然后系统知道如何对它们进行优先排序，这样您就可以避免这个问题。
在某些地方，您可能会发现服务器以 100% 的速度运行是不好的。CPU 为 100% 的服务器表明流程中存在瓶颈。您可以使用更多 CPU 或更快的 CPU 来生产更多产品，但只要您对吞吐量感到满意，就可以了。您可以将其想象成一个商店，所有店员都总是很忙。这可能不太好，因为更多的顾客无法在那里购物，因为他们得不到服务。
但是，如果我们有一个仓库，里面有需要分类的物品，没有特殊的截止日期，并且接下来的 5 年有足够的工作，那么你会希望每个人都全力投入工作，不让任何人闲着。
如果仓库靠近商店，您可以做一些联合的事情：让店员为顾客服务，当没有顾客时，他们会提前对仓库进行分类，直到下一位顾客到来。
传统上，您拥有某些专用硬件，您可以自行决定使用多少。但在 AWS 这样的模型中，您拥有更多选择。（注意：我假设您的任务由许多小的、易于并行化的块组成）
- 只要需要，就使用大小为 X 的单个实例
- 使用大小为 X+n 的更快实例
- 使用速度较慢但更便宜的实例，需要更多时间
- 使用多个实例
在某些情况下，您可以以一个大实例为代价使用几个较小的实例，从而获得更多的结果（而对于其他任务集则不会）。
此外，成本并不是固定的。在非工作时间启动额外的实例可能会让你受益，因为那时成本更低，而在成本更高时减少它们。假设你可以借用附近商店的店员（以一定的可变费率）。24 小时营业的商店可以很乐意让你让夜班的员工以相当低的成本对仓库中的一些物品进行分类，因为只有少数顾客会经过。但是，如果你想在黑色星期五多雇人手，那就要贵得多了。（事实上，最好那天不要让任何人对仓库进行分类）
AWS 允许您执行大量动态负载，当您不必在 X 时间内做出响应时，您可以显著优化成本。但是，它们有“太多选项”，而且很难理解。您还需要很好地了解您的工作负载，以便做出正确的决策。
答案4
这取决于
某些工作负载（例如机器学习、3D 渲染、媒体转码、加密货币挖掘）设计为以 100% CPU 运行(*)。这些类型的工作负载通常经过优化，将其任务划分为相等形状的块，并充分利用每个指令流水线机箱上每个 CPU 的利用率。如果您在这些情况下抱怨 CPU 利用率达到 100%，您的同事会认为您是个白痴。您的问题没有提到任何这些专门的工作负载，因此请继续阅读。
另一方面，对于一般业务工作负载，您经常要处理过于复杂且编写不当的软件，这些软件必须以不可预测的时间间隔处理不规则块中的任务。对于这种类型的工作负载，由于“并发症”，CPU 不足可能导致系统不稳定和死亡螺旋。其中一些“并发症”包括不可预测的内存利用率、数据库连接、数据库锁定和超时配置。
示例：假设您有一个进程，当它独享 100% 的 CPU 时，需要两分钟才能完成，但当它必须与其他四个进程共享 CPU 时，时间将增加到 10 分钟。现在假设每个进程在运行时始终持有一个外部数据库连接，并且连接池会回收超过 10 分钟的连接。然后...
嗡嗡嗡。
这是你的传呼机在半夜响起的声音，因为这个批处理作业神秘地失败了，而这个批处理作业还没有修改过。个月，因为数据库连接数已达到最大值，或者连接持续时间开始超过配置的 10 分钟最大值。随着进程进入重试模式并且新任务到达，死亡螺旋开始，很快您甚至无法获得任何遥测数据或登录实例。
(*) 我们暂时忽略 GPU 绑定的工作负载，这将是一个全新的问题。