1 前言
----------
最近一直在维护一个线上运行的旧系统，系统本身的问题很多，然而又有大量客户准备试用。之前一直存有侥幸心理，希望系统能神奇的顶过这段时间，但这个蜗牛般的系统残忍的告诉我们——我们被客户给投诉了。现在真的不得不正视这个问题并且需要快速的解决掉。
2 处理
----------
2.1 初步分析
=============
之前也初步分析过这个问题，定位在连接池那里有问题。现象是有大量的“Cannot open connections”的报错，dump出来的线程状态大部分都是停在等待获取连接那里。原先认为是dbcp连接池有问题，因为数据库那边的active连接数很低，后来把连接池的当前状态一直打印出来，发现连接池给出的当前active连接数却很高。我们先升级了dbcp的包，但是问题依旧。那么就开始调整连接池的参数，但是几经调整，在100个左右用户同时在线的情况下还是很容易崩溃。我们开始思考是不是到底问题是出在哪里了。
2.2 压力测试重现问题
=====================
这个时候最需要的就是压力测试来稳定重现问题，但这么紧急的情况下又没人会，怎么操作，难不成现装现学LoadRunner？！这个时候有个朋友给了一个非常好的建议，利用ab来模拟并发，直接请求某个action。这个很简单，就是手动登录一下系统，然后记录下来sessionID，再找到某个action需要提交的参数并写入一个文件，这里叫postdata.txt，最后执行ab -C sessionID=xxx -p postdata.txt -n 1000 -c 100 http://xxx/xxx.action。
刚开始感觉很奇怪，每次连接池中active连接到50多就会挂，但是具体数值还不是一个稳定的值。几经查找，在数据库那边查看当前session数量的时候发现居然是数据库最大连接超出了150的限制。
2.3 问题的修复
==============
接下来自然是怎么解决这个问题了。
在连接池参数中，我们反复测试，发现如果把maxactive调到一个很低的值，很容易报错。具体报错看了一下，是Timeout waiting for idle object，明显是等待连接超时了。那么自然想到去修改等待连接的超时时间，我们把maxWait从3000调整到8000，这样报错几乎就没有了。但这个参数修改是有一定问题的，因为用户可能要等8秒才能得到响应。这里主要是把maxActive调整到一个比较大的值。
对于数据库最大限制做了一下调整，processes调到300，sessions调到了335，这样暂时就没问题了。但是查到官方建议是中型应用是100个连接，大型应用是200个，我们这个怎么可能会用到这么多呢。这个问题在后面的教训中给了我们答案。
2.4 整装上阵
=============
我把以前出问题的日志和内存状态dump都那出来了，并把我们测试的是出问题时的情况做了对比，确实是一样的。基本可以确认我们找到了问题的原因。这个时候开始满怀信心的升级线上系统了。升级过程很顺利，但是悲剧再一次重演。
当用户登录人数在两百人的时候，系统已经慢的和蜗牛一样了。这个时候拿出日志发现连接池中激活连接居然达到了maxActive中设置的150，又开始有大量的连接超时，同时我们发现网页打开速度也奇慢无比。理论上当前的人数并不多，数据库慢也许是有各种可能，但tomcat应该完全有能力支持到这个情况的。我们系统真的有这么龊吗？
2.5 命悬一线
=============
这个时候已经比我们答应用户处理完问题的时间又过了10分钟，大量用户在线等的都已经非常焦躁不安了。但我们已经把之前分析得到的优化方案都用上了，貌似也没起到任何作用，而且这个时间已经也不允许我们做任何更复杂的优化了。正在这无比气馁的时候，有个同事想到可能是防火墙之类的问题吧，就索性把360给关掉了。奇迹终于发生了，系统的响应速度和数据库连接的速度大幅度提升，瞬间400多人同时登录上线速度还都嗖嗖的，数据库active连接最大也没超过30个。我真的恨死360了，这个给普通用户用的东西怎么能装到服务器上呢，这玩意对网络连接肯定是做了很多审查才导致速度严重下降。幸亏问题虽然没按时解决，但还算及时解决了，后来一圆场还能对付过去。心里一个石头放下了，突然身体也觉得非常疲惫。
3 总结
-----------
总结些什么能，难道是发现360不能在服务器上使用？！这当然是气话，这个过程还是有很多收获的。简单总结一下：
1）利用ab可以非常简单的模拟出并发访问，针对web程序更可以直接针对每个action进行测试。
2）对于复杂问题的解决，还是要先能稳定重现问题，这样才能更容易分析定位问题，从而找到有针对性的解决方案。
3）遇事冷静，要针对现象找到有确实可行、合理的解决方案。
4）最后不得不补充一下，别用360，特别是在需要提供服务的服务器上。
本文转自passover 51CTO博客，原文链接：http://blog.51cto.com/passover/578817，如需转载请自行联系原作者
