尽管容量规划的大体方法相同,但容量规划其实是一个迭代的过程,不可能一劳永逸,需要
在实际验收中不断调整。即使在回归方程已经确定的情况下,由于业务是不断变动的,依然要跟
着修改方程。根据历史运行趋势,并根据模型估算未来资源需求,根据实际情况不断修正模型,
优化参数,使估算更趋于合理。 尽管种类繁多的互联网服务最终是让有限种类程序模块来执行,但每个模块的特性却是各不相同
,消耗的资源也不尽相同,衡量的标准难以把控。尤其是随着业务的拓展,模块、业务、集群关
联会越发复杂,在这样一种模块和业务在多样化的前提下,不可能用一种统一的建模方法涵盖所
有模块中的所有业务,必须根据模块的实际情况来分别建模。 通常情况下,样本数据越多,越能反映大多数的状态,拟合的模型也就越精准,方程的拟合优度
越高,因此,我们在实际建模时,对一个模块采用尽可能多的样本,我通常采取三百个样本以上
。另一方面,不应该用线下测试环境中的数据建模,毕竟它的访问请求并不符合用户行为,用此
样本创建的模型必然会有误差。生产环境中的样本数据是最真实、直接的样本。为了使模型更为
有效,最好是用当天的数据来建模。根据模块的特性,如果只是起到分配转发,不涉及深入计算
及io操作的话,基本上访问量和CPU利用率成正比,这保持强线性关系。这一典型模块就是各种
调度器,如lvs、nginx和lighty等。有的模块涉及深入复杂的计算及io操作,不同的请求会有不同
的CPU消耗,比如MySQL的一个慢查询比10个普通检索还消耗CPU,对于这种情况,请求数有
可能和CPU利用率不成线性或不成正比,因此,有可能需要用到非线性方程。 拟合优度只表示对现有样本拟合的优劣程度,不能做为模型好坏的标准,任何模型必须有实际
意义才行,因此,必须要以实际意义为准。一般情况下,级数越高的多项式拟合效果越好,但
估算效果却差强人意,因此,将多项式拟合限制在2元多项式。初步选择的模型是几种基本模
型,如果当某个模块的样本散点图不符合任何一个基本图形时,可以通过几种方法来解决。
(1)一律采用多项式来拟合。(2)通过扩大样本周期取其平均数的做法使其线性化。(3)
将复杂曲线按照基本图形划分成几个阶段,分段回归。(4)选择更复杂的回归方程。另外,
一般模块在配置文件中都配置了极限请求数,因此,当预估的流量超过该值时,我们视该模
块的容量达到100%。
还没有评论,来说两句吧...