事情的原因，是发生在某个晚上的9点30左右，SAE的报警系统突然报出了异常，所有的Wb服务器的负载突然变得很高，流量也变得异常的大。这个是很有问题的，在SAE最前面的反向代理上，是部署了SAE自己开发的‘CC防火墙’的，如果出现了异常的被攻击的情况，这些异常的流量是不会到达Wb服务器的，现在这些流量都到达了Wb服务器，说明要么是攻击没有被正常判断，要没就是这不是一次攻击。
事实上确实这也不是一次攻击。
随后的分析，我们发现了一堆比较‘奇怪’的应用，为什么说‘奇怪’呢，因为这些应用的访问趋势是这样子的：
这是其中一个应用的数据，然而在这个应用的帐号下面，大约有十个类似的应用，都是这样的趋势，所以对于我们的Wb服务器来说，在特定的时刻要接受接近10倍左右的流量，对于当前的规模就有点‘顶不住’了。
所以讨论过后，大家的想法还是要对Wb服务器进行扩容，来满足这样突发的流量增长。但与此同时，Wb服务器也有些不一样的异常，在报警的时候，系统负载比较高，CPU也没有什么空闲了，但是有个比较特殊的现象，就是systm占用的CPU比usr占用的CPU要高，这是明显不合理的，一般情况下，systm占用CPU较高意味着系统可能存在瓶颈，比如大量的锁争用等情况。
所以，在着手准备扩容Wb服务器的同时，也尝试对现有系统进行一些性能分析，看是否能找到瓶颈，便于做一些优化，提升单Wb服务器的容量。
分析的第一步，就是要收集系统运行时的信息，因此我们使用了prf这个工具，在系统中对