最近在压力测试下我们出现了一些BUG，比较棘手，我在各位思想基础上总结如下解决办法。
1：一定要先尽快解决简单问题，在干净基础上进行测试。
这样干扰因素会减少，因为压力情况下出现的BUG很棘手。这也是我们把压力测试放到功能测试后面的原因。
例如修改虚拟池的简单BUG就干扰了现在的压力下的BUG。所以再把这个问题解决后要再次进行压力测试。
2：解决BUG一定要结合当时的测试方法和测试目进行分析。
我们设计了很多压力测试方法，不是盲目和罗列的，而都是有目的和针对性的。
例如登陆进去后打大量的连接，就是为了测试 代码中接受连接并根据目的地址建立到后面的连接的地方。
登陆进去后下载大量数据，就是为了测试代码中数据转发的地方。
所以当解决BUG时候，不要仅仅看core dump的堆栈，应该结合当时的测试方法，根据测试目的分析BUG。这样才能有针对性地对问题进行处理。
3：对于交织的问题处理
当前两个地方： ssl session 和 assert(client.fd)出现都可能是产生BUG的原因。
ssl session 已经找到解决办法，我觉得基本可行，但是为什么还是出问题呢？
所以要采用同样的测试方法，再次打压力，如果core dump还是出现在client.fd的地方，基本就是证明client.fd的问题。
如果堆栈地方还是很乱很随机，则可能是内存乱了的问题。
当前要高度怀疑client.fd，这个地方songqinga以前解决过，反复多次，至少涉及两个以上交织的BUG，对这个地方还是理解不透彻。要仔细分析。
4：要从方法论高度来思考和分析。
各位思考过这个问题吗？为什么在通常的情况下不出现问题，在高压力下就出现问题呢？
假设每个进来的连接都是按照一个单一的流程处理，从原理上讲，大量的连接也必然是按照相同的流程处理的。
如果小压力这个流程正确，则大压力下这个流程也是正确的。但是实际情况是高压力下出了问题。
是什么原因呢？最大的原因就是高压力下进入了别的异常分支流程中了。
但是为什么进入别的流程呢？我根据经验总结起来有如下几个原因：
A: CPU太忙
cpu太忙，则对后来的连接无法处理。导致进入异常流程。
例如CPU太忙，无法进行大量的RSA计算，导致后面的SSL session无法建立。ssl 握手协议发现在指定timeout内不能建立成功，则进入sslabort中进行异常处理。
B：内存分配不成功
系统为每个进程可分配的内存都是有限制的。例如每个进程最多不能超过多少页虚拟内存。
同时对内存分配的速度也是有限制的，假设你在一个循环中不断malloc，发现失败概率就很高，如果加一个间隔延迟，则基本都能分配成功。
所以当大量连接到达的时候，要么内存不够用，要么因为分配速度过快，导致失败。
所以要对每个内存分配的地方要做检查。
C：每进程资源限制（例如连接限制）。
系统默认对每个进程都是有资源限制的。
通过ulimit 可以显示和限制每个进程的资源。例如限制最大的可打开的句柄或者可允许建立的最大连接。
当连接过多，达到这个限制，则TCP连接建立失败，则进入异常流程。
所以要研究ulimit的限制，从每个限制地方入手，尤其是连接限制。所以说即使系统资源够用，但是每个进程的还是有限制的。
当然有人可能说，我们可以通过操作ulimit来让系统资源最大为我所用。这个思路是对的。但是要从整体考虑分配资源。
但是这样也解决不了压力BUG问题，因为只要压力足够大，还是能达到你的最大值的。
所以要对可接受处理的资源进行限制，不能超过 ulimit的限制，这也是一条思路。一个系统没有容量限制是要出问题的。
所以看来设计一个高性能高稳定性，能承受高压力的系统还是具有很大挑战性的。
5：根源和具体BUG并进
通过方法论能分析出根源，但是根源能产生很多分支，所以要从根找到具体BUG的工作量很大。但是从根上找就可能一劳永逸。
从具体BUG上来找，可能最后难于找到根源，只能就事论事，导致最后还是疲于奔命。
所以我们要从两方面并进，汇合，这样代价更小，效率更高。
我个人经验有限，思维可能有局限性，所以需要借助众人的智慧想出更完善和彻底的方法，希望各位多提建议。
也希望向博和zhailang能把交换机方面对高压力情况下BUG的处理的一些经验介绍给我们。或者找到具体精通的人给我们做一些解答。
可能应用层的高压力处理和网络层的高压力处理有一定差别，但是一些思想还是可以借鉴的。