写点什么

为什么超过 80% 的资源利用率会成为任何系统的噩梦

  • 2016-02-24
  • 本文字数:1411 字

    阅读完需:约 5 分钟

Skipjaq ,我们关注应用在最高可持续负载状态下的性能表现。在此状态下,应用的负载不至于过饱和乃至崩溃,但也没有丝毫空闲,可以说是该应用性能最真实的体现。我们尤其关注的是,应用在临近极限情况下会产生怎样的延时。

在最近的一次有关 Web 应用延时的团队讨论当中,我提到一个通用准则:延时在服务利用率(utilisation)超过 80% 之后会呈现明显的恶化。再说得确切一点,是服务等待时间(wait time)的恶化导致了延时(latency)的恶化。

John D. Cook 为此撰写过一篇很长的文章进行说明,不过我想再补充一些更深入的说明,以便于没接触过队列理论(queuing theory)的读者们理解。

服务即队列

80% 这个数字来自于队列理论。首先,我们看一下为什么 Web 应用服务符合队列理论的模型。

假设我们正要测量一个 Web 应用(服务)的延时,该应用运行在单台服务器上。请求到达服务并被处理掉。如果在一个新请求进入的时候,该服务仍然在处理之前的其他请求,则新请求就需要排队等待。出于简化的考虑,我们假设该队列可以无限延长,并且任何进入队列的请求都仅在服务完成其处理之后才离开队列。

对于本场景而言,最简单的队列模型是 M/M/1 模型。M/M/1 是 Kendall 标记法,此处的通用形式是 A/S/c,其中 A 代表到达过程,S 代表服务时间分布,c 代表服务器的数量。

在本处简化的场景中,我们只有一台服务器,所以 c = 1。模型中的 M 代表马可夫(Markov)。马可夫式的到达过程描述了一个泊松过程:每两个请求到达的间隔时间呈指数分布,其参数为;马可夫式的服务时间分布也描述了一个泊松过程:完成一次服务的时间呈指数分布,其参数为

队列利用率

我们所说的服务利用率,其定义为:服务用于处理请求所花费的时间百分比。对于上述M/M/1 队列而言,服务利用率的计算方式为:

队列在时处于稳定态,这符合直觉:如果单位时间内的新增请求数大于被处理完毕的请求数,则队列将会无限延长。

延时的计算

利特尔法则是从队列理论推演出的最有趣的结论之一。简单来说,在一个稳定系统当中,客户的平均数量(L)等于其到达率()与每个客户在系统中平均耗时(W)的乘积:

对于每一位客户而言,其在系统中的平均耗时就相当于是该客户所感受到的延时。该数值由服务时间和等待时间两部分组成。直觉上,平均服务时间基本上是固定的,所以延时的变动主要取决于等待时间的变动。

我们现在关心的是延时,所以让我们把公式转换到另一边:

也就是说,如果我们知道系统中的平均客户数量,我们就能够计算出等待时间。在一个M/M/1 队列中,客户数量的平均数的计算方式为:

具体的推导过程不在本文中赘述,感兴趣的读者可以参阅这篇文章

上面说过,服务利用率,所以:

这样,我们就有了一个有关延时与到达率、服务完成率之间关联性的简化公式。现在我们进一步想要得到延时与利用率之间的关联公式,这就需要套用到上面的公式中:

综上所述,我们已经假设服务时间是固定的,即:是常量。所以,延时与成比例关系。将该公式画成图表:

可以明显看到延时在利用率超过80% 之后就开始飙升。利用率越接近100%,延时越倾向于无限大。

结论

延时在服务利用率超过80% 之后迅速恶化。所以为了避免在生产环境手忙脚乱的处理延时问题,我们应当监控系统利用率,确保其不超过80% 的危险范围。

给系统进行性能测试的时候,让系统负载到80% 以上的结果往往都是延时无法达标,而让系统负载到接近100% 则意味着你要等很久才能拿到测试结果!

英文原文: Relating Service Utilisation to Latency

2016-02-24 18:005870

评论

发布
暂无评论
发现更多内容

精益管理| 河南钢铁集团:以盈利型采购生态应对复杂的市场挑战

用友BIP

GraalVM 静态编译下 OTel Java Agent 的自动增强方案与实现

阿里巴巴云原生

阿里云 云原生 可观测

喜报!钛铂数据 TapDB 通过中国信通院文档数据库产品测试

tapdata

国产数据库 TapDB 国产分布式文档数据库 钛铂分布式文档数据库 中国信通院测试

如何从自建开源 Prometheus 迁移到阿里云托管 Prometheus 服务

阿里巴巴云原生

阿里云 云原生 Prometheus

ETL vs. ELT:数据集成的最佳实践是什么?

tapdata

etlelt区别 什么是ETL 什么是ELT 数据集成最佳实践

店铺商品搜索API返回值中的商品标题、图片与价格解析

技术冰糖葫芦

API Explorer API 编排 api 货币化 API 文档

AI项目验收!用友助力鑫阳钢铁进入智能判钢新时代

用友BIP

Gartner《IT服务管理平台市场指南》报告解读

嘉为蓝鲸

ITSM Gartner gartner中国 IT服务管理

SLS 数据加工全面升级,集成 SPL 语法

阿里巴巴云原生

阿里云 云原生 服务日志

你在找提升效率的解决方案还是追求效果的解决方案

客户在哪儿AI

内容营销 ToB营销 大客户营销

gin框架上手实践

FunTester

中石化中海燃供总会计师刘汉坤:一场数智革命,对内打破部门墙,对外抢占先机

用友BIP

多重认可!嘉为科技入选《Gartner 2024中国基础设施战略成熟度曲线》

嘉为蓝鲸

AIOPS Gartner 可观测 OpenTelemetry

领先实践| 能源央企构建世界一流司库管理体系

用友BIP

活动预告|8月3日 Streaming Lakehouse Meetup · Online 与你相约!

Apache Flink

StarRocks 实时湖仓 paimon

从消息流平台Serverless之路,看Serverless标准演进

华为云PaaS服务小智

Serverless 华为云

职场<火焰杯>测试开发大赛决赛成绩及获奖名单公布!

霍格沃兹测试开发学社

TapData 信创数据源 | 国产信创数据库达梦(Dameng)数据迁移指南,加速国产化进程,推进自主创新建设

tapdata

达梦数据库 达梦数据迁移 达梦增量同步

观测云与传统监控:差距究竟有多大?

观测云

监控

为什么超过80%的资源利用率会成为任何系统的噩梦_语言 & 开发_sai_InfoQ精选文章