yangjianxv
作者yangjianxv·2017-08-22 09:36
部门总经理·成方金融科技有限公司

排队论下的系统响应时间

字数 2608阅读 7436评论 1赞 3

一个OLTP系统,当吞吐量增大后,响应时间往往也增大,尽管吞吐量没有到达整个系统的容量上限。本节从排队论的角度介绍响应时间和吞吐量的数学关系。

我们假设一个系统有1个进程处理业务,那么同一个时刻只能处理一笔业务,假设此时来了10笔业务,那么后面的9笔业务都需要排队等待,这样就形成了响应时间的延长。

假设这个系统把进程数量增加到10个,10个进程并发处理业务,你会发现,虽然等待队列里面没有业务,但是,这10个业务的平均响应时间会比单独处理1个业务的时候长。这是因为,虽然前台服务(处理业务的进程)没有争用和等待,但后台却有争用和等待。比如,数据库锁的竞争、内存栓锁的竞争、多进程写一个日志的竞争、对CPU时间片的竞争、对网络IO的竞争、对磁盘IO的竞争等等。

因此当一个OLTP系统吞吐量增大后,不论吞吐量是否达到系统上限,往往都会出现响应时间增大的情况。这种情况的根本原因在于“各层面的组件”对资源的竞争,从而引起了排队、响应时间增大。

如果一个业务仅仅等待一种资源,那么可以用排队论来清晰地解释。然而,计算机系统里面的一个业务不可能仅仅等待一种资源,而是等待多种资源,不同层面的资源,这些资源之间的关系错综复杂,例如,一个业务的处理同时需要两类资源,会出现持有资源A、等待资源B的情况。

因此,在计算机行当里面,性能能达到什么水平,从来都没有嘴炮,从来都没有模型,do the fucking testing, 来,用跑分软件跑一遍。因此,各个细分的领域都有跑分软件,比如交易类的系统我们用TPC这个委员会的TPCC这个基准程序来衡量一个系统的能力。

然而,话又说回来,即使没有完备的模型来解释性能,那么简单的、不完备的总有吧。这就是今天我们要介绍的排队论。排队论是个数学里面的理论,实在烧脑,这里就介绍一个最简单的例子,展示一下“吞吐量没有达到系统上限,响应时间增大的情况”的数学解释。由于有些烧脑,可以直接跳到黑体字看结论

业务等待进程去处理,就相当于顾客去服务台接收服务,例如:

2.png

2.png

3.png
3.png

4.png
4.png

排队论里面的参数也是蛮多的,排队系统的符号表示,其一般形式为:X/Y/Z/A/B/C,其中
X:顾客到达时间间隔的分布
Y:服务时间的分布
Z:服务台个数
A:系统容量
B:顾客源数量
C:服务规则

例:(M / M / 1 /∞/∞/FCFS)表示:
到达间隔为负指数分布,服务时间也为负指数分布,1个服务台,顾客源无限,系统容量也无限,先到先服务。

描述一个排队系统运行状况的主要指标有:

  1. 队长和排队长
  2. 等待时间和逗留时间
  3. 忙期和闲期(这个本节不介绍了)

上述一些主要数量指标的常用记号:
N(t): 时刻t系统中的顾客数(又称为系统的状态),即队长;
Nq(t): 时刻t系统中排队的顾客数,即排队长;排队长+正在服务的长度=队长
T(t): 时刻t到达系统的顾客在系统中的逗留时间;
Tq(t): 时刻t到达系统的顾客在系统中的等待时间。

记pn(t)为时刻t时系统处于状态n的概率,即系统的瞬时分布。我们将主要分析系统的平稳分布,即当系统达到统计平衡时处于状态n的概率,记为pn。又记
N:系统处于平稳状态时的队长,其均值为L,称为平均队长;
Nq:系统处于平稳状态时的排队长,其均值为Lq,称为平均排队长;
T:系统处于平稳状态时顾客的逗留时间,其均值记为W,称为平均逗留时间;
Tq:系统处于平稳状态时顾客的等待时间,其均值记为Wq,称为平均等待时间;

λn: 当系统处于状态n时,新来顾客的平均到达率(单位时间内来到系统的平均顾客数);
μn: 当系统处于状态n时,整个系统的平均服务率(单位时间内可以服务完的顾客数);
当λn为常数时,记为λ;当每个服务台的平均服务率为常数时,记每个服务台的服务率为μ,则当n≥s时,有μn=sμ。(即s个服务台,整体的服务能力是单位时间完成sμ个顾客)
顾客相继到达的平均时间间隔为1/λ,每个服务台的服务率为μ,那么单个服务台的平均服务时间为1/μ。令ρ=λ/sμ,称ρ为系统的服务强度(即整个系统有sμ的处理能力,但单位时间内只来了λ,所以就处理了λ个顾客)。

  1. 队长的分布
    记pn=P{N=n}(n=0,1,2,…)为系统达到平稳状态后队长N的概率分布,并注意到λn=λ,n=0,1,2,…和μn=μ,n=1,2,…记
    ρ=λ/μ
    设ρ<1,则

5.png

5.png

平均队长L为:

6.png

6.png

**ρ为系统的服务强度(即整个系统有sμ的处理能力,但单位时间内只来了λ个顾客,所以就处理了λ个顾客,ρ=λ/sμ为系统的服务强度)。ρ<1
假设现在系统吞吐量比较小,只有20%的饱和度。那么平均队长是 0.2/(1-0.2) = 0.25.
假设现在系统吞吐量比较大,有80%的饱和度。那么平均队长是 0.8/(1-0.8) = 4.
也就是说,只有一个服务台,这个服务台的处理能力足够处理这些顾客的请求,在这个个非常简单的模型下面,当服务台的服务强度比较大的时候(比如说80%的CPU利用率),这时候整个队列(包含正在被服务的那个顾客)竟然平均有4个人。**

平均排队长Lq为:
7.png

7.png

关于顾客在系统中的逗留时间T,可说明它服从参数为μ-λ的负指数分布,即
8.png

8.png

因此,平均逗留时间W为:
9.png

9.png

因为,顾客在系统中的逗留时间为等待时间和接受服务时间之和,即T=Tq+V。其中,V为服务时间,故由

10.png

10.png

这个逗留时间(等待时间和接受服务时间之和)可以理解为系统对业务的响应时间=1/(μ-λ)+1/μ。

假设现在系统吞吐量比较小,只有20%的饱和度,(假设λ=1,单位时间内来一个顾客,有1个服务台,s=1;服务台的处理能力是单位时间处理5个顾客,μ=5,最后得到服务强度,或者说饱和度λ/sμ=0.2)。那么顾客的逗留时间是 1/(μ-λ)+1/μ = 1/(5-1)+1/5=0.45个单位时间.

假设现在系统吞吐量比较大,有80%的饱和度(假设λ=4,单位时间内来4个顾客,有1个服务台,s=1;服务台的处理能力是单位时间处理5个顾客,μ=5,最后得到服务强度,或者说饱和度λ/sμ=0.8)。那么顾客的逗留时间是 1/(μ-λ)+1/μ = 1/(5-4)+1/5=1.2个单位时间.

另外,平均等待时间Wq为:

11.png

11.png

欢迎大家与我留言,也可以关注个人微信公众号:性能测试与调优

二维码8cm.jpg

二维码8cm.jpg

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论1 条评论

EndlessRainEndlessRain(网吧资深的网管)网吧
2017-08-22 10:45
感想! 我觉得当下最大瓶颈首要的还是体现在CPU的处理机制上面,而不是处理能力。 在计算节点,RAM可以堆叠到几个TB,内部总线可以通过PCIE并行处理。存储系统也扩展到了几个微秒延迟的Flash。只有CPU的“处理机制”仍然保留在原始方式。虽然摩尔定律仍然在运作,CPU的处理能力也越来越高。最终导致的是,CPU的利用率和处理能力两极分化严重。 其实,对比OLTP业务,队列对于目前的SSD厂商也产生了很对阻碍。 我个人接触了很多国内Flash /SSD厂商,现在一颗NVMe PCIe SSD轻松可以到达50万IOPS。让他们沮丧的是插10颗同样的SSD在计算节点,无论如何也跑不出500万IOPS。这是CPU单线程-“串行”处理机制诟病。尤其是热度增高,时钟频率被夷为平地。 此,文章所说的:“假设这个系统把进程数量增加到10个,10个进程并发处理业务”,这种并发其实我个人觉得并不是真正意义上的“并发-Parallel”,这只是软件厂商对现代CPU处理机制一种改善,例如多线程技术,时间分片技术等等。其最终效果仍然是对CPU单一核心(Core)的最大利用,以及对IO队列伪装成“并发-Parallel”效果。 减少IO队列最直接的办法就是让CPU可-并行计算。多线程技术,时间分片技术,以及更快的SSD磁盘也能缓解,但并不会像CPU并行计算那样——直接面对问题。真正CPU“Parallel IO”是促使所有CPU之所有COREs同时或自适应处理所有的IO任务,缩短更快的完成时间。这需要大部分应用程序重新编译,或提供扩展CPU驱动程序。 早期(90年代初)IBM,优利系统,包括几个小公司致力于这一技术,后来被雪藏,不过相信这个技术很快会再次华丽登台。年初的时看过XXX公司一次R&amp;amp;D内部测试视频(保密材料),那是2颗基于E5 2696 v3 CPU,72个logical processors,当手动逐步开启这个72 logical processors,队列中的IO被一批一批吞掉,场面何其壮观。 一篇资料 JUST FYI.:Parallel vs. Serial Processor https://www.techwalla.com/articles/parallel-vs-serial-processor
Ctrl+Enter 发表

本文隶属于专栏

作者其他文章

相关问题

X社区推广