rin*_*ogo 11 centos amazon-web-services centos7
在仅运行nice后台处理作业（即不存在 Web/DB/etc 服务器）的机器 (AWS m5.large) 上，始终以 100% 运行 CPU 是否有缺点？
我知道运行系统使其消耗 100% 的可用内存并不是一个好主意。如果没有交换，系统将在内存不足时简单地终止进程。即使使用交换，系统也会开始交换页面，这会显着降低整个系统的速度。
但是，我的理解是，具有niced 进程以 100% CPU 使用率运行的系统将正常运行而不会显着减慢。这样对吗？
或者，尝试配置后台进程使系统保持在 60% - 90% CPU 使用率范围内会更好吗？
Tim*_*Tim 21
只要系统在做您需要的事情并且对登录和更改做出响应，运行 100% CPU 就没有问题，这就是它的用途。Nice 只改变进程的相对优先级。
在 AWS 中，如果您使用 100% 的 CPU，请避免使用 T 系列实例，因为它们会提供部分 CPU。在 CPU 分配上，为承诺的 CPU 获得 M（通用）/C（计算密集型）/其他系列 VM 比使用“T2/T3 无限制”更便宜。
为了发表评论，AWS（以及我假设其他领先的云提供商）没有针对 CPU 的“合理使用”政策，这往往来自低端提供商或共享主机。如果您为核心付费，则可以 100% 使用核心。如果您的实例未得到充分利用，AWS Trusted Advisor 服务会推荐较小的实例以帮助您节省资金。
在本地，您显然可以随心所欲。这个答案是常见的情况，适用于云，特别是 AWS。
不管你是否nice，以 100% CPU 运行意味着你没有尽可能快地处理你的工作，如果你有更多的 CPU 可用。整个系统确实变慢了。唯一能nice为您做的就是让您指出哪些进程具有更高或更低的优先级，并且应该或多或少地拥有您已经有限的 CPU。
如果您的作业比您预期的要慢，那么唯一能产生显着差异的就是为它们提供更多的 CPU。如果您从其他工作中获取它，那么这些工作就会放缓。如果你升级你的 CPU，那么一切都会运行得更快。当然，既然是EC2，你也可以添加更多的实例。
小智 5
以 100% 运行 CPU 没有问题。
即使在不太可能的情况下，您的特定硬件存在导致过热的冷却问题，因为这是 AWS 服务器，这也是亚马逊的问题，而不是您的问题（请放心，他们在定价模型中考虑了这一点）
如果它不做那项工作，它就会闲着，所以如果你需要完成 $job，最好让它去做。你不想人为地限制它。
主要缺点是以 100% 连续使用 CPU 将需要更多功率。但是您希望完成这项任务，对吗？¹
（¹请注意，在某些情况下，例如比特币挖矿，电力成本高于开采比特币的价值）
其次，如果系统 CPU 以 100% 的速度完全使用在执行一些不太重要的任务（例如处理 SETI 数据包），则可能发生更重要的事情（例如所有者的交互式请求），但计算机没有不要太及时注意，因为它正忙于处理这些数据包。这可以通过处理不太重要的任务来解决。然后系统知道如何对它们进行优先级排序，您就可以避免这个问题。
在某些地方，您可能会发现让服务器 100% 工作是不好的。CPU 为 100% 的服务器显示该过程中存在瓶颈。您可以使用更多或更快的 CPU 生产更多产品，但只要您对吞吐量感到满意，就可以了。您可以将其视为所有店员总是忙碌的商店。这可能很糟糕，因为更多的顾客无法在那里购物，因为他们无法得到服务。
但是，如果我们有一个仓库需要分拣物品，没有特殊的截止日期，并且有足够的工作供接下来的 5 年使用，那么您会希望每个人都全职工作，而不是让某人闲置。
如果仓库在店铺附近，你可以做组合：你让店员为客户服务，当没有客户时，他们会提前分拣仓库，直到下一个客户到来。
传统上，您拥有某些专用硬件，您可以或多或少地使用它。不过，在像 AWS 这样的模型中，您有更多选择。（注意：我假设您的任务由许多小的、易于并行化的块组成）
在某些情况下，您可以使用几个较小的实例来获得较大实例的成本，从而获得更多结果（而对于其他任务集则不会）。
另外，成本不是固定的。您可能可以通过在非工作时间启动额外的实例而受益，当它们更便宜时，但在更昂贵时缩小它们。假设您可以借用附近商店的店员（以一定的可变利率）。24 小时营业的商店很乐意让您让夜班员工以相当便宜的方式对您的一些仓库物品进行分类，因为只有少数顾客会经过。但是，如果您在黑色星期五想要一些额外的手，那会贵得多。（其实当天最好不要有人离开整理仓库）
AWS 允许您执行大量动态加载，当您不必在 X 时间内响应时，您可以显着优化成本。然而，他们有“太多的选择”，而且理解起来很复杂。您还需要非常了解您的工作量，以便做出正确的决定。
| 归档时间： |
|
| 查看次数： |
3972 次 |
| 最近记录： |