尽管容量规划的大体方法相同，但容量规划其实是一个迭代的过程，不可能一劳永逸，需要

在实际验收中不断调整。即使在回归方程已经确定的情况下，由于业务是不断变动的，依然要跟

着修改方程。根据历史运行趋势，并根据模型估算未来资源需求，根据实际情况不断修正模型，

优化参数，使估算更趋于合理。

 

 

 

尽管种类繁多的互联网服务最终是让有限种类程序模块来执行，但每个模块的特性却是各不相同

，消耗的资源也不尽相同，衡量的标准难以把控。尤其是随着业务的拓展，模块、业务、集群关

联会越发复杂，在这样一种模块和业务在多样化的前提下，不可能用一种统一的建模方法涵盖所

有模块中的所有业务，必须根据模块的实际情况来分别建模。

 

 

通常情况下，样本数据越多，越能反映大多数的状态，拟合的模型也就越精准，方程的拟合优度

越高，因此，我们在实际建模时，对一个模块采用尽可能多的样本，我通常采取三百个样本以上

。另一方面，不应该用线下测试环境中的数据建模，毕竟它的访问请求并不符合用户行为，用此

样本创建的模型必然会有误差。生产环境中的样本数据是最真实、直接的样本。为了使模型更为

有效，最好是用当天的数据来建模。根据模块的特性，如果只是起到分配转发，不涉及深入计算

及io操作的话，基本上访问量和CPU利用率成正比，这保持强线性关系。这一典型模块就是各种

调度器，如lvs、nginx和lighty等。有的模块涉及深入复杂的计算及io操作，不同的请求会有不同

的CPU消耗，比如MySQL的一个慢查询比10个普通检索还消耗CPU，对于这种情况，请求数有

可能和CPU利用率不成线性或不成正比，因此，有可能需要用到非线性方程。

 

 

拟合优度只表示对现有样本拟合的优劣程度，不能做为模型好坏的标准，任何模型必须有实际

意义才行，因此，必须要以实际意义为准。一般情况下，级数越高的多项式拟合效果越好，但

估算效果却差强人意，因此，将多项式拟合限制在2元多项式。初步选择的模型是几种基本模

型，如果当某个模块的样本散点图不符合任何一个基本图形时，可以通过几种方法来解决。

（1）一律采用多项式来拟合。（2）通过扩大样本周期取其平均数的做法使其线性化。（3）

将复杂曲线按照基本图形划分成几个阶段，分段回归。（4）选择更复杂的回归方程。另外，

一般模块在配置文件中都配置了极限请求数，因此，当预估的流量超过该值时，我们视该模

块的容量达到100%。