容量规划(一)

上期讲了我个人对容量规划的一些想法，本周开始了实验性的工作，总结起来如下：

本周主要针对我们线上的一个前端WEB集群，做了次比较深入的体检，过程如下：

1。信息收集工作

    既然是体检，就需要知道详细的细节。从配置系统里面读出集群列表，然后从监控系统中读取出了如下数据：

1天CPU使用率

内存used使用

traffic RX包

disk IOPS数据

http Established状态数据

log中记录的response数据

上述数据涵盖了机器的CPU,内存，disk，网络的信息，基本算比较全面了，数据均5分钟一笔

2。 数据分析。

将上述数据处理，以散点在图上展示，通过展示，发现了如下规律：

traffic RX包的曲线与HTTP Established曲线最为接近。

CPU使用率曲线与上述2条曲线较接近，但是波动幅度小于上述2条曲线。

MEM与CPU，流量，http session数关系不大，但是在上述3条曲线出现峰值的情况下，MEM使用量有所上升，但是波动幅度较小

总集群的响应时间曲线不随着traffic和session的变化而变化，很平的曲线。

上面的最后一条分析结果让我很郁闷。。。当时以为是我数据出现了问题，因为理论上系统的压力应该随着访问量的增长而增大，当然，响应时间也应该随之增长，但是很奇怪，系统压力上来了，但是响应没有任何变化！在考虑很久以后，突然知道了原因：系统空闲，哪怕CPU增长了，但是系统仍然在最低压力范围内，所以响应时间不会有太大的变化。。。

3。 总结

    通过对上述数据的分析，我们得出如下结论：

 1) 该WEB应用属于CPU依赖型应用，session的增长直接影响到CPU的使用率，需要将CPU作为该集群容量规划的主要参数

 2) CPU与session的增长率并非是1:1的关系，也就是说session增长率曲线陡，但是CPU的增长率曲线要缓一些，具体的曲线拟合方程暂时还没计算出。

 3) 当前web集群空闲，机器有富余，短期可以不考虑机器扩容，甚至有可能从该集群中拿掉多余的机器以控制成本

OK，后续对集群压力测试，以及该集群的容量预测在下周开始搞吧，各位有兴趣可以持续关注下~