大型网站服务器容量规划

版权信息

书名：大型网站服务器容量规划

ISBN：978-7-115-42525-6

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

•　著　　　　郑　钢 　 贺亚涛　 尤胜涛

　 责任编辑　张　 涛

•　人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

　 邮编　100164 　电子邮件　315@ptpress.com.cn

　 网址　http://www.ptpress.com.cn

•　读者服务热线：(010)81055410

　 反盗版热线：(010)81055315

内容提要

本书讲解了用数学回归分析方法来做服务器容量规划的思路，让读者掌握服务器容量规划的量化方法；模型的选择是服务器容量规划的关键，不同的程序有不同的模型。本书使用nginx+PHP+MySQL为实例演示了具体的规划过程，以便达到触类旁通的作用，使读者具备构建复杂模型的能力，以解决服务器容量规划的实际问题。本书还介绍了服务器容量一般监控的技术及实现方法，如整机CPU、进程CPU、进程IO等。学习完相关章节后，读者也可以编写监控程序了。

本书适合互联网行业运维工程师、测试工程师、技术经理、项目经理、产品经理，以及致力于从全局把握运维和优化网站的所有互联网从业人员。

推荐序（一）

你很幸运能拿到这本书，更重要的是，你的公司老板也会很幸运。郑钢在这本书里深入而系统地分享了构建大型网站服务器容量规划技术的方方面面。从方法到思路，从需求分析到系统设计，涉及诸多算法原理和实现细节。通俗的语言，流畅的叙述，将枯燥复杂的技术原理娓娓道来。

我曾经在工作中和许多运维人员有过技术上的交流，在讨论到服务器容量规划的问题时，大家都会提到灾备冗余，需要根据流量负载，并发峰值综合考虑，然而当进一步探讨到服务器容量规划不凭经验估计，通过公式来计算量化时，就语焉不详，难以深入下去了。凭经验，不依靠监控系统及科学算法，无法给出准确的量化数据，这无疑会限制公司在大型并发网站下的运维能力。

这本书将为你提供运维高性能网站的服务器容量规划的完整解决方案。郑钢有着在百度运维大规模服务器集群的实际工作经验，他精通运维系统的技术和架构。当知道他将花时间著作一本网站服务器容量规划的书时，我不禁为许多运维人员感到高兴。据我所知第一次有像本书这样全面详细地阐述服务器容量规划。尤其是有关系统和核心模块的细节披露，都是来源于实际运维中总结出来的经验，没有这样的经历，你甚至很难想象系统会是啥样的结构。

不要犹豫了。当你拿起这本书，按照书中所分享的技术方案去实践时，你会发现，规划服务器容量就这么简单。我相信，越来越多的网站运维需要用到这方面的技术，掌握它并加以实践，你和你所服务的公司会获益良多。

联想/大数据平台技术总监　杨汇成

推荐序（二）

服务器容量规划对于互联网企业控制成本具有重大意义。本书从理论和实践上对此做了详细的阐述，指导运维人员不再单纯“凭经验+逐步尝试”来判断是否需要扩容，可以通过用回归分析等建立数学模型的方式，更加科学地量化服务器容量并制定解决方案。本书提出的方法具有普适性，对服务器容量规划以外的其他业务、其他方向也具有很好地启发作用和借鉴价值。

奇虎360/政企云事业部经理　冯顾

服务器容量规划对于一个大型互联网公司来说是一项不可或缺的研究课题。一个合格的运维架构师必须对这些了如指掌，本书是较为难得的参考工具书之一。

美丽说/运维架构师，前百度核心运维工程师　陆景玉

《大型网站服务器容量规划》是一本学习如何计算、如何预算业务服务所需服务器容量的科学性方法的指南，本书讲解了从科学理论到实践的整个过程，非常符合精细化运维的发展方向，是一本很好的书籍。

美丽说/高级系统工程师　要凯

容量规化是保障服务可用性的前提，它是任何IT企业都可能会面临的难题。本书通过对实际生产环境的解析来阐述容量规化的重要性，是一本理论结合实际的非常好的教科书之一，书的内容通俗易懂，让读者读起来容易，理解并应用起来也更容易。

百度/高级运维工程师　朱玉杰

有幸与郑钢共事一年有余，蒙郑钢悉心指点，于精神、技术、生活、健康等诸方面均有受益。今闻其又一新作问世，第一时间拜读后，收益良多。随着电商与互联网金融如雨后春笋般迅速发展，以及容器技术的不断普及，对线上资源的评估和利用已经成为一个比较核心的技术，这个技术一直困扰着我，阅读本书后，我在这本书里找到了答案。不得不说，郑钢的书是一如既往地令人期待，特此推荐，谨望诸君阅读后皆有收获。

美图/底层工程师　徐阳

从上大学的时候认识郑钢到现在已经7年多了，每次和他聊天都受益匪浅，被钢哥对技术追求的工匠精神所折服，作为郑钢的朋友和忠实读者，真挚地向大家推荐这本书，因为你只需要一个月的时间认真研读，就可以学到郑钢几年的研究成果，真是物有所值。

金山云/高级技术经理　 成志龙

我们经常说，“人无远虑，必有近忧”，服务器容量规划讲的就是“远虑”。作为运维人员，我们如何充分利用服务器的每一份资源来满足业务需求，如何在满足业务需求的前提下，更好地控制我们的成本，凸显服务器的价值，是尤为重要的。《大型网站服务器容量规划》这本书以深入浅出的讲解方式，让我们很容易理解其中的奥秘，通过阅读本书人人都可成为容量管理的高手。

Mobvista/运维总监　黄梦溪

服务器容量评估规划，是一个高级的运维管理课题，能够做好这个课题的运维团队和公司并不多。和郑刚在百度一别之后，有幸加入了嘀嘀打车，目前在一家潜力股的医疗大数据公司就职，希望和所有在创业公司拼搏的伙伴一起，从郑刚的书里学习服务器容量规划的技术，弥补缺漏的知识。

医渡云/运维负责人　孙楠松

前言

当今社会已经进入信息时代，人们足不出户，从网络上就可以获取自己需要的信息。为了满足正常的业务需求，任何一个网站都要有硬件支持，无论日访问量是一个百万级的中型网站还是上亿级的大型网站。为了正常响应用户请求，都必须提前规划好业务容量。互联网的快速发展使得网站的流量无法预估，因此，网站的运维人员必须随时监控流量，随时扩容以应对大流量带来的压力。目前业内容量规划的方法有以下几种。

一种方法是凭经验。根据以往的运维经验和目前系统的监控信息来判断是否需要扩容。这种方法明显的缺点是不可靠，即使是操作人员自己也会觉得没把握，一旦失误，造成的损失比较大。

另一种方法就是投入更多的硬件支持。足够冗余的硬件可以大幅度地提升服务的稳定性，但硬件的成本是很高的，不能通过无止境地硬件采购来保证服务质量。

以上的“凭经验”和“大量硬件投入”的方法暴露了这样一个问题：业内需要一套科学地容量规划策略，需要找到服务器容量量化的方法。为解决这个问题，本书给出了一种能够将服务器容量“量化”的方式。

将服务器容量“量化”的核心技术是资源监控与回归分析，因此，本书提出的容量管理系统是计算机资源监控系统与统计学的应用结合，将监控信息制作成样本数据、对其建模，找出访问量与资源消耗的公式是本书的中心思想。与一般的服务器容量监控系统不同，为了使样本数据精确匹配，在本书实现的监控系统中，有关访问量的监控信息必须和CPU的采样时间及采样周期吻合。

互联网公司是用计算机来支撑业务的，业务必然会消耗计算机中的资源，这些资源包括CPU、内存、存储、网卡等。不同业务主要消耗的资源是不同的，存储型业务，如百度网盘，其主要业务就是存储用户的文件，计算机资源的度量就是存储空间；对于计算型业务，如游戏行业，其主要业务就是游戏引擎的计算，主要用CPU支撑；对于流量型业务，如优酷，它的主要业务就是通过网卡传输视频文件，主要就是消耗网卡及网络带宽。所以，可以用计算机的物理资源来衡量业务量。而无论哪种业务，都少不了CPU的消耗，因此，本书采用CPU利用率作为一般业务的度量，这对于其他方面的容量管理具有抛砖引玉的作用。

掌握了容量管理技术后，运维人员便能够掌握系统还可以再承载多少流量的压力、对于新增加了的流量需要添加多少台服务器、冗余机房是否可以承载全部流量、为节省公司资源应当下架多少台服务器，以及待上线的项目是否会给线上服务带来压力等，过去凭经验完成的工作将变得可“量化”，这样会使运维工作更加透明和科学。

最后，感谢我的家人对我的支持和理解，感谢我的女友王小兔（我对女友的爱称）对我的照顾，在今后的日子里我会更加努力来回报你对我的关心。

本书读者答疑QQ群为117613587，本书编辑联系邮箱为zhangtao@ptpress.com.cn。

第1章　容量概述

1.1　容量规划背景

如今人们已经习惯从互联网上获取信息，因此，几乎任何一家公司都要有自己的网站。引入了一个新的事物后，必然会随之带来新的问题。网站是放在服务器上的，一般来说网站的访问量越大，服务器的压力就越大。为保证网站的正常运营，网站的运维人员有必要了解当前系统是否工作正常、系统的处理能力是否接近极限，以及需要新增多少台服务器来承载新增的压力。作为一名合格的运维工程师，对于以上这些必须要做到心中有数。

一般的公司在网站扩容方面都是采用“凭经验+逐步尝试”的方法，这样通过逐渐逼近的方式得到系统的极限承载量。再专业一点的公司，会让运维人员搭建一套线下的测试环境，测试人员先在线下对各种关键URL做测试，通过分析测试报告找到系统的极限值。这种方法只能得出个大概值，因为真实的压力取决于用户的行为和当时的代码运行情况。

第三种方法是在线切换流量，也就是将一部分流量导入到某些服务器上，观察日志，直到出现报错为止，然后再将流量切挽回到其他机器结点上，这种方法能够得到最真实的系统压力，但毕竟牺牲了部分用户体验。

以上3种方法的共性都是单次有效，下次换了新的代码环境还要重新手工测试。除了以上的方法外，还可以利用一些系统命令做监控，每天做出容量报表，通过查看报表运维人员便监控到系统的实时压力及实时容量，当逼近根据经验判断的压力上限时，发出报警，提醒扩容。还有的公司是利用监控系统，找到半个月内的系统最大流量作为未来短期内的流量预估，基本上也是靠经验。

上述方法都不能正确地得到系统所能正常承载的极限压力，总的来说都是依靠经验或牺牲用户体验为代价。本章讲解的内容是将系统的极限压力量化为具体的数据，进行更为准确的容量规划。

1.2　容量研究的意义

容量管理的基本目标有两个，一是使运维人员了解系统的承载力，二是以合理的硬件成本来满足业务需求。减少成本是企业生存的刚性需求，技术人员同样有责任在技术层面上帮助公司节约成本。在软件方面，开发人员通过改进程序算法来提升系统的工作效率；在硬件方面，运维人员除了规划服务架构，还要根据业务类型定制专用的服务器，有针对性地提升系统性能。无论在硬件还是软件方面，都是在原有服务的规模下通过提升性能来减少硬件成本。除了以上两个方面，还可以通过硬件容量规划的方式进行最直接的成本控制，容量管理一方面是节约硬件成本，另一方面节约了人力成本。

为方便陈述，我们这里所说的容量管理是指服务器容量管理。容量管理主要用于评估各集群模块在当前及未来流量下的利用率，让系统容量“可见”。

模块的性能表现和实际运行的指令息息相关，并不是一次测试便能适用所有类型的代码环境，因此，当有新项目上线或在原有基础上扩容时，较安全的做法是，需要重新评估机器性能用以考量服务的稳定性。容量管理可以量化服务的稳定性，测试人员可以专注于业务本身的测试工作，无须再做稳定性测试。

技术人员还要负责硬件成本预算的工作，在提交预算时要反复权衡服务成本与稳定性。对于预算中的刚性需求，技术人员必须提供充分的理由予以支持，需要一套有效的数据作为预算的依据。有了容量管理系统，任何时候都可以用数据说话，系统需要多少台机器不是技术人员决定的，而是由业务流量决定，这样就为技术人员分担了预算压力，使他们能够更加专心地投入工作。

1.3　容量研究的目标

目标是实现单入口流量预估，具体包括以下内容。

（1）判断现有系统规模还可以再承载多少流量。

大家应该有这样的经验，一到假期，大家花费在网络上的时间会很多，也许会发现网站的响应有可能会变慢。对于网站来说，假期的流量比一般时候的流量要大，因此，在节假日的流量会有所上涨。我们可以估计出新的流量来判断现有的系统是否可承受。

（2）对于新增的流量，采购设备时给予指导，花最少的钱办同样的事。

公司一般会在每个季度做一次预算，因此，要提供一套理论公式支持部门的预算申请。对于运维部门来说，就要用数据来说话了，提供容量公式是最好的证明。

（3）流量切换时可以量化。

为了保证服务稳定，通常会提供双机热备，有时保险起见，会提供多余的一套设备。或者为了提速，提供的服务会划分为多个冗余系统，当某个机房的服务出现问题时，为保证正常服务，需要将流量切换到另一个机房。切换多少流量过去呢？这时候容量系统就派上用场了，为了不至于“压垮”另一个机房的系统，需要事先知道另一个机房的系统容量还有多少空余。

（4）优化服务规模。

产品服务中的机器数未必是最优的，容量管理可以根据访问量和指定的容量利用率，自动计算出需要的机器规模。

以上几点是容量规划要实现的目标，后面将逐步介绍。

第2章　容量规划简介

2.1　什么是容量

容量意指容量规划，从经济学到工程领域都有其应用，容量规划听起来是个高大上的概念，本质来说，其实就是资源利用率的管理，一个较典型的例子就是容器，例如我们是用水杯来接水喝，水杯总是有一个最大容量，我们所接的水肯定都在杯子容量之内，超过这个容量水就会溢出，这个道理还是很易懂的。其实在接水这个动作发出之前，我们通过观察就已经知道了杯子的最大容量是多少，所接的水必然会控制在杯子容量之内，如果一个杯子容量不够，口渴的同学可能会选择更大的杯子或者同时用两个杯子。因为这是潜意识里的行为，尽管你可能没有注意到，其实这就是在做容量规划。说到这我猜你也看出来了，容量规划的前提是，只有在事先知道系统可承载的最大压力的情况下才能做好流量控制和容器分配。杯子的容量是很直观的，我们在接水之初已经掌握了其容量大小，因此，可以方便地控制接水的流量和速度，然而很多抽象的容器其容量并不直观，因此，容量规划就是针对不容易测量容量的容器，通过一系列方法找到其最大容量，在此基础之上再做更细粒度的规划管理。

容量是指一个系统可处理容纳的最大能力，这个能力可以简单理解为访问量，即流量。如某个网站正常情况下可承载的流量是8000万PV，超过了这个流量，用户请求的处理将受到影响，如响应变慢，或者干脆返回空白页。因此，8000万PV的访问量便是这个网站的容量。可见，网站的容量规划极其重要，如果因为容量不足而影响网站业务的话，对于互联网公司来说，给公司带来的损失很可能是很惨重的。对于一个公司来说，服务运维是保证业务稳定的核心，规划好服务的容量是保证业务稳定的前提。

容量规划和性能优化是两个经常被混淆的概念，它们相互影响，但却是有着不同的目标。性能优化是最大限度地提升系统的性能，比如对内核参数、模块参数的调优，不过调优提升的性能有限，在起初调优的作用是非常明显的，到后来基本上就到了极限，已无潜力可挖。而容量规划是想找出相应服务质量对应的硬件规模，与硬件是否调优关系不大，因为在调优前后，这两种状态下相应的容量也是不同的。比如在调优之前，系统可承载的最大流量相对较小，调优之后，系统可承载的最大流量就增多了，不过这对容量来说不重要，容量与调优并不冲突，它们是两码事。总之容量规划并不是性能优化，它们虽然相互影响，但却有着不同的目标。性能优化是最大限度地提升系统的性能，而容量规划是在成本和性能之间找到平衡点。

对真实系统压力的测量比任何经验估算都靠谱，我们应该以实际容量的观测数据来驱动未来容量的预测，而不是简单通过极限测试等方法来模拟。如果没有找到测量系统容量的方法，则不能科学地对系统进行容量规划，而只能根据业务类型、经验去猜测，这种情况则仁者见仁智者见智。

2.2　服务器容量规划的源由

为什么要做容量规划呢？当资源涉及的成本变得非常可观时，势必就需要容量规划，谁也不愿意花冤枉钱。

做运维工作的读者都应该了解SLA（Service-Level Agreement），即服务等级协议，这是关于网络服务供应商和客户间的一份协议，其中定义了服务类型、服务质量和客户付款等术语。可能我们不那么关注这份协议的细节，但我们最了解的是SLA中的“几个9”，如表2.1所示。

表2.1　SLA

根据产品线的重要程度，公司会将不同产品线划分成多种级别，每种级别产品线的SLA也是不同的。如一级产品线的SLA可能是99.999%，二级产品线可能是99.99%，为保障产品线的稳定，各产品线的项目经理给每个运维人员都制定了关键绩效指标，即KPI（Key Performance Indicator）。运维人员都清楚，保证产品的服务稳定是我们的职责，即使不签KPI我们也会竭尽全力地投入到工作中（尽管完不成KPI的话可要扣工资的），所以，运维人员对服务的稳定性特别敏感，但凡会让服务不稳定的因素，运维人员都会将其排除，如下架服务器。

通常，为了业务的稳定，大多数公司在硬件，如服务器方面的投入都是过饱的，认为机器越多，服务越稳定，宁可闲着不用也要确保业务不受损。因此，空闲着很多机器资源，所以很多时候，大公司的运维部发愁的是机器该如何使用。

一般情况下，公司服务器的总体资源利用率长期处在较低水平，CPU利用率都在20%左右，总的来看，我们有大量的计算资源和存储资源闲置，造成巨大浪费，这也直接导致我们的服务成本偏高。所以，提供同样质量的服务，我们可以减少一些服务器，以更低的成本来实现。

各部门都有自己的理由，公司财政方面又很有压力，于是需要在成本和服务稳定性方面找个平衡点，要花更少的钱提供同样稳定的服务，于是容量管理项目就浮出水面。

想想为什么运维人员会拼命把机器留住呢？无非是担心机器资源减少后会导致服务不稳定，如果给运维人员提供一套容量规划的方法，让容量“可见”，让运维人员对服务质量放心，那么下架机器就不会那么为难了。

总的来说，容量管理系统对于提高资源利用率，降低服务成本有着可观的经济效益。

2.3　容量规划的对象

容量可以指任何系统的资源利用率，本人结合工作内容，论述服务器硬件方面容量管理。

无论您公司是什么业务，只要业务是用计算机来承载，必然可以用计算机的物理资源消耗量作为业务量的度量，这体现在处理器、硬盘、内存、网卡、网络链接数等方面。业务量与计算机资源消耗量整体上是呈正比的。

在做容量规划之前，要清楚自己的业务是何种类型，这取决于业务主要消耗了计算机中的哪些资源，容量规划必须要结合业务类型。

根据不同的业务类型，从大体上可以分为。

1．计算密集型的业务

计算主要消耗的是CPU资源，因此，计算密集型也称为CPU bound，业务处理过程中主要用到了CPU资源，CPU使用率随着业务的繁忙变化而同步变化，此类业务中对处理器的要求非常高，CPU通常都是16核，甚至是24核以上服务器，即使是这样的配置，在计算密集型业务中也经常会出现所有CPU核心全部占用的情况。尽管没有纯粹消耗CPU资源的业务，其他资源像磁盘IO、网卡等或多或少都要有所涉及，但它们相对较少，可以在一瞬间完成，因此可以忽略。

2．I/O密集型的存储业务，这包括出入网卡的流量

I/O密集型也称为I/O bound，是指业务处理过程中，主要使用的是I/O资源，比如硬盘读写、用网卡的上传和下载，因此CPU利用率不高，即使处理业务的最繁忙时段，CPU负载也很低。

3．数据密集型业务

数据密集型业务也称为DataIntensive，主要体现在大数据应用中，比如著名的搜索引擎就是从海量数据中找到有用信息，通常这类业务非常占用内存资源。缓存也是数据密集型业务，如squid、varnish，典型的应用就是cdn，cdn本质上就是个cache，它将请求的结果缓存到内存中，避免将请求转发到源站。

以上是典型的3种业务，没有某个业务纯粹属于某种类型，因此，容量规划的对象也是以这3个特征为代表，找出业务主要的特征类型，针对此类型进行规划工作。

2.4　容量管理的目标与收益

虽然我们在QA那里能够获取到各应用模块的性能数据，但在新项目上线或原有基础上扩容时，仍然需要每次重复评估服务稳定性，这说明我们在平时的工作中对服务系统的容量没有很直观的认识，对系统资源的可用率，我们需要量化。

为了让大家更直观地看到系统的已用率及剩余可用率，在此展开容量管理相关的工作。容量管理的主要目标用于评估各集群模块当前及未来某流量下的容量状态。

为方便陈述，我们这里所说的容量管理是指服务器容量管理。

容量管理的基本目标是以合理的硬件成本满足业务需求。其实我们平时所做的很多工作都是在完成这一目标，比如开发人员改进程序算法，提升处理能力。运维人员根据业务类型，定制专用的服务器。而我们的容量管理，从表面上看是在管理服务器，其实容量管理一方面是节约硬件成本，另一方面节约了人力成本。

每季度在做预算时，这是公司全体技术人员头痛的时候，虽说服务器运维和开发人员关系不大，但按照以前的做法，运维人员需要向开发人员索取申请机器的理由，开发人员就要自圆其说地给出一套理由，而运维人员根据申请的机器数又要酌情删减，这样才好向上面交待，大家都是走个“形式”。有了容量管理系统，我们可以用数据说话，要多少机器不是我们说了算，是业务“说”了算，这样就可以使技术人员更加专心地投入工作。

容量管理还可以节约人力，这体现在服务扩容方面。扩容就是在集群中增加结点，就意味着包括以下工作：

（1）服务环境部署；

（2）关联模块配置；

（3）同步定时任务；

（4）向数据中心注册；

（5）向操作中心注册；

（6）对内部系统的权限申请；

（7）代码同步；

（8）数据同步；

（9）开启服务；

（10）qa回归测试；

（11）应用上线。

以上仅是增加一台结点时所做的基本工作，而且其中每一个环节都不能出错。另外，向内部系统申请权限是要花时间成本的，通常需要一两天的时间，这就意味着，为了应急突发事件引起的扩容，需要提前准备一些已申请权限的机器在备机池中，听上去就感觉好累，这些都是运维人员的工作。

为减少盲目扩容时付出的人力成本，提前知道目前的系统还能支撑多久。比如在节假日时流量会增长，为保证服务稳定，只好按经验添加机器。

机房由于物理原因可能导致不可用时，用户将无法访问到服务。例如用户在访问某网站时，突然该网站所在的机房出现了问题，不管是运营商的问题还是机房建设的问题，总之，为保证用户的业务访问，必须将流量切换到其他机房或运营商上运行，这在之前，为了避免压垮对方机房的服务器，都是一点一点尝试做的，如先切换5%的流量，观察一会后，没有问题，再切换10%的流量，之后再胆大点，切换20%的流量，这种循序渐进的切换方式，必然也会造成用户的请求失败，如果涉及金钱交易，对公司的损失想必是非常大的。有了容量系统，我们知道对方机房的容量后，这样便可一次性地把流量切换过去。

另外，当系统服务过于冗余时，为了节省资源，我们通常要在集群中下架一些服务器，这通常不是下架一两台，少则十几台，多则几十台。下架机器并不是简单地把服务器关掉就行了，需要在上下游通过各种配置，把下架的机器屏蔽掉，保证没有流量才行。这通常牵扯到上游服务，也需要申请，所以，下架服务器既需要人工成本，也需要时间成本。万一机器被下架的太多，可能随时重新扩容。有了容量管理系统，该下架多少台机器是通过计算得出的，没有人工干涉，可以让运维人员更踏实。

最另人欣喜的是，容量规划还可以帮我们找出模块最大可正常处理的请求数。

模块一般都有配置文件，就拿PHP来说，其配置文件php-fpm.conf中配置了PHP进程可处理的最大并发数，每个请求的最大执行时间等。之所以可以这样配置，原因是PHP内部都有个“仲裁器”，由它来控制管理处理的请求，当请求超时时，它会将请求“杀掉”。显然，这部分被“杀掉”的请求已不属于被正常处理的，容量规划可以找到正常处理请求数的最大值。

总结，容量管理系统给我们带来的收益如下。

（1）科学地评估系统所用的资源是否合理。

（2）科学地预测未来资源的增长，并进行合理的预算采购。

（3）运维人员以科学的方法对资源进行有效管理，这包括优化集群中结点机器数量，预知服务可承载的最大压力，预知系统何时性能燃尽等。