服务器 CPU 长期保持在 80%以上，会有什么影响？

• 資深大佬 : d0m2o08

  费电

• 資深大佬 : kiracyan

  可能会被突然的业务增长干掉

• 資深大佬 : surbomfla

  会导致 CPU 长期保持在 80%以上

• 資深大佬 : dennisun

  会性价比高，会物尽其用，会绿色环保

• 資深大佬 : vueli

  @surbomfla 听君一席话,甚是一句话

• 資深大佬 : Remember

  会导致焦虑症，频繁去查看 load average.

• 資深大佬 : salmon5

  owner 不是我，就没影响

• 資深大佬 : TerranceL

  会比较想换更好的 CPU 让负载降下来

• 資深大佬 : minbaby

  业务上：对于突发的流量击溃宕机，导致服务中断。
  物理上：就是全天 100% 使用，只要保证良好的散热，不会影响 CPU 性能，也不会损坏 CPU 。
  心理上：没有监控的时候焦虑拉满，有监控的时候短信轰炸

• 資深大佬 : superchijinpeng

  发挥了它的价值

• 資深大佬 : IvanLi127

  会导致有不到 20% 的 CPU 性能被浪费了，建议在空闲时间再安排点任务给他。

• 資深大佬 : securityCoding

  比较危险

• 資深大佬 : brucewar

  资本家，榨干他的剩余价值吧！

• 資深大佬 : iqoo

  剩下 20% 用来挖矿，设置 nice 优先级最低

• 資深大佬 : Ephzent

  会导致 20%CPU 没有被使用

• 資深大佬 : marcong95

  会导致 CPU 积分用光

• 資深大佬 : konakona

  @IvanLi127 哈哈哈哈哈 资本家

• 資深大佬 : jsion

  如果做过一些优化，技术性能数据能满足业务，那么长期保持说明资源利用率被高效利用了，而很多研发根本不管运维成本，很多机器资源都是闲置浪费的。
  如果担心有问题，至少保证服务不是单点，做多节点水平扩展高可用，最建议上云（基于 kvm/container 技术），根据负载状态动态伸缩资源

• 資深大佬 : wudaye

  @IvanLi127 狠还是你狠

• 資深大佬 : Orenoid

  偶尔发生波动会有些风险呗

• 資深大佬 : pengtdyd

  这表示还有 20%的资源没有被利用，严重的资源浪费！！！

• 資深大佬 : kidult

  如果都是你这种“优质”客户，云厂商只能关门

• 資深大佬 : p2pCoder

  流量波动不大

• 資深大佬 : jellyspot

  先吐槽，这问题问的，毫无提问的艺术！！！
  如果不会有波峰波谷，一直很稳定，那说明你的设备利用率还是不错的
  如果有波动，有 cpu 打满导致服务异常的风险
  顺便问下，每天我回家都要一个小时，如果长期这样，会有什么影响>_<

• 資深大佬 : neilyoone

  CPU 有点累???

• 資深大佬 : mestrace

  现象 /影响：这里讨论一下 OLTP 在线业务（ i.e. 一个对外提供服务接口的 server ），具体现象就是，响应时间持续提高，大量请求积压，最终导致无法服务。
  理论：排队论（ Queuing Theory ） M/M/1 模型描述了这种 OLTP 的模型，即请求随机，服务时间随机。在此系统下，一个请求的响应时间为 T=1/mu * 1/(1-rho)，其中 mu 为结束的概率，rho 为服务利用率。如果将这个图画出来，可以看到，当利用率超过某区间时，响应时间便急剧加长。
  启发：在在线服务中，应当尽量控制资源的利用率。

• 資深大佬 : iColdCat

  哈哈哈哈哈哈哈 听君一席话如听一席话

• 資深大佬 : adoal

  财务：这服务器买的值……但可不可以利用率更高
  运维：已经需要考虑业务波动带来的可用性风险了
  开发：程序是否有较大优化余地

• 資深大佬 : hankli

  可能会产生可能会产生的影响

• 資深大佬 : locoz

  说明资源利用率高，在留有一定余量的同时没有浪费资源，挺好的。

• 資深大佬 : cnrting

  说实话不到 90%我都觉得钱花得不值

• 資深大佬 : smileawei

  如果是云主机。恭喜你。你的钱花的值。风险嘛。就是万一有一波业务高峰，就没什么弹性了。

• 資深大佬 : sherryqueen

  会来 v 站问有啥影响
  如果业务稳定, 这个利用率挺好的. 不过还是考虑下 程序是否有优化空间 或者 是否可能会有突然的业务增长

• 資深大佬 : 4771314

  如果是稳定的 80%左右的话，还好，可以把监控的阈值适当调高一点
  如果波动很大的话，那就很危险了

• 資深大佬 : goodryb

  如果是自己玩，那无所谓；
  如果是生产建议升配或者扩容，80%已经是非常高的水位了，这个时候业务延迟已经开始变大，如果遇到业务量进一步上升，有可能无法响应。

• 資深大佬 : guo4224

  高负载才是大家的正常期望，利用率提高 1%，每个月都能省下来几百万。

• 資深大佬 : buddyy

  @mestrace 赞，这才是正解啊。

• 資深大佬 : aaronlam

  其实如果一直能稳定保持 80%，利用率不是才是最好的吗？

• 資深大佬 : Cielsky

  @jellyspot 会导致你回家需要 1 个小时

• 資深大佬 : ArianX

  如果流量比较高的话，会导致整体时延上升，同时导致部分长尾请求超时。为了维持比较高的 SLA ，在生产环境中我们尽量保持高峰时延在 60% 以下

• 資深大佬 : pmispig

  建议先跑 20%的垃圾计算线程把计算资源占了，等有业务需求来再让位

• 資深大佬 : chenyu0532

  强迫症的人受不了吧。。

• 資深大佬 : tailf

  一看就是在臆想，别说 80%了，就算是 50%，已经有很多用户开始卡了

• 資深大佬 : opengps

  如果是稳定的 80%没啥问题，如果峰值争用，那么很多程序会卡顿，甚至处理不当挂掉

• 資深大佬 : 786375312123

  @aaronlam 取决于你做什么事情，如果是 batch processing 这种，大不了先切换优先级高的工作。如果是直接的客户服务，那就怕来个大流量服务就完蛋了

• 資深大佬 : xe2vforesu

  @kiracyan @minbaby 业务突然增长，流量突然增长可以讨论一下，
  我觉的如果系统做了限流，资源隔离，业务突然增长，流量突然增长也没关系，多出来的请求会被拒绝，一个良好设计的系统，应该能确保服务不会处于过载状态，且能保证 cpu 会在业务高峰时段处于相对固定的繁忙比例，比如 80%

• 資深大佬 : pythonee

  @adoal 服务：马上识别敏感用户