3.4 通过回归方程规划容量
回归方程是统计学里面的知识，是一种应用数学，通常属于数学专业同学研究的方向，运维人员很少用这种方法评估系统容量。下面花点时间引出回归方程在服务器容量规划中的应用，这也是本书介绍的重点。
容量规划的关键就是找出系统可承载的最大压力，然后根据极限压力再做部署规划，话说的容易，其实这往往是最困难的部分，因为它不像杯子那种容器，其容量是很直观的、可以提前确定。而服务器的性能是不好估量的，看不到摸不着，其容量只能通过实际测试才能得到。再说，我们所运维的系统可是由数以千计的机器组成的，这么多机器对系统的容量都起到决定性的作用，而且大多数情况下各个机器的性能是不一致的，一台机器的容量数据不能作为其他机器的标准，总之各服务器都有自己的极限容量。就像电池一样，有的电池容量较大，2600毫安，有的容量较小，2000毫安，因此，它们各自的续航时间是不同的。
容量评估就是用现在的数据预估未来的变化，用什么方法来预估呢？在正式回答之前，咱们还是用数据说话，先看几张监控图，也许大家就明白是怎么回事了，如图3.3所示。
图3.3中显示的是流量与整体cpu_idle之间的关系，上面的access_log_pv是每分钟的访问日志，下面的cpu_idle是每分钟的cpu_idle，大体趋势上这两张图是对称的，这两张图表明：访问量越大，CPU利用率就越高。其实不说大家也会这么想，访问量越大，相应的CPU使用率当然就越高了。其实这是在正常时的情况，在某些情况下，访问量越大，CPU使用率越低，您信不？后面我们再讲。
下面再看图3.4，这是流量与流量之间的对比，注意并不是流量与CPU利用率。
一般的网站都会有前端模块和后端模块，前端模块则是实际的流量访问入口，图3.4中的下图lighttped_log是入口模块的访问日志，上面的图front_ms_log则是后端模块的访问日志，这两个日志的时间统计粒度是一样的，都是每分钟内的访问量。front_ms_log每分钟是15个左右，lighttped_log大概是每分钟1000个，虽然这两个日志数量级差别很大，但它们在总体上的趋势是一样的，front_ms_log随lighttpd_log的变化趋势而变化，因此，这两张图中的曲线依然相似。
以上的两张大图虽然一定程度上说明了问题，但似乎还不够明显，毕竟它们展现的是入口流量与整体CPU的关系或前后端模块的流量关系，也就是监控粒度是整体。下面再看图3.5，这里的监控粒度是模块，也就是某个Server，如nginx。
图3.5中，front_ms.log是php-cgi的日志，php-cgi_proc_CPU是php-cgi的使用率，从图3.5上看这两者的关系确实明朗了很多，几乎完全是一样的趋势。这是模块pv与模块消耗的CPU对比，针对的是模块。另外说明一下，由于系统中任何一个模块的CPU使用率、或者整机的CPU利用都是由其流量驱动的，入口流量又以一定的比例分流到后端，因此，几乎是系统内的任意流量都与系统内的任意模块CPU利用率之间保持某种关系，简而言之，未必是模块自身的流量与模块自身的CPU利用率之间才呈现关联关系，也许只是这种关联关系比较明显而已。有关这一点可以通过监控图来验证，把所有机器、模块的流量和CPU监控放到一起对比，会发现趋势线是类似的。
从上面3个大图来看，这些流量都是相关的，即保持某种依赖关系，流量越大，CPU消耗、后端流量等都跟着增加，如果把这一关系用函数y=f(x)来表示的话，其中的x表示流量，y便是CPU消耗或者后端流量等相关的因素，找出x与y的关系就是容量规划设计的思想。以上图中的监控信息可以用来生成样本数据，这种由已知的样本去预估未来的变化趋势，是典型的回归应用，容量规划的核心思想就是曲线拟合。