apache部署集群jkstatus中busy数过高
项目背景：采用SSH架构，tomcat部署，apache负责集群，terracotta负责session共享。在我们维护某项目的初期，当访问我们的web服务的用户数过多时，会出现apache的JK Status Manager中Busy数过高，当达到某一峰值，我这里遇到的Busy数是300左右时，对应tomcat将宕掉。我们采用了一种我称为反向定位Bug的方法。此方法不像以往的只能定位到是哪个action发生错误，而无法更加具体而详尽的定位到是哪个action中的哪一段代码有问题，也无法还原现场，即工程师无法将这个Bug重现。反向定位Bug方法可以有效的查找出是哪个用户在哪个时间段做了哪些操作造成系统问题，并能有效的定位到出现问题的代码段。下面做以介绍：1、找出JK Status Manager中Busy数过高的那几个Tomcat
2、查看对应Tomcat Manager Application中Server Status的信息
得到下述Server Status的信息：
在此处，可以看到是哪个IP提出了哪种Request请求导致Busy数过高。此图片只是用来举个例子，并不是实际中出现Busy过高时的图片。
3、在我们的数据库中用户登录记录表中，会有IP和用户账户的对应关系，就可以查出是具有哪种种权限的哪个用户在何时使用了这个应用。此应用即上述Request下对应的应用。
4、对Bug重现，进行分析。
最终，我们发现我们系统Busy数过高，并不是因为服务器性能不足造成的，而是以下两个代码问题造成的：
1、系统有两条复杂的SQL语句，查询结果可以达到上亿条，使得执行到此查询时，需要耗费30分钟左右的时间。
2、在action中未规范使用Spring事务处理语句。
此两个问题，导致oracle出现严重的锁等待现象，通常会出现数以千计的锁。解除oracle锁，可以查看我的《批量解决oracle锁等待的方法》一文。
出现问题1的原因是某些程序员在select中使用了过多无用的表，并将这些无用的表连接起来，导致拼凑出大量无用的查询数据。删除这些无用表即可。若不行，您可以考虑经此处的业务逻辑尽量简化一下。
过来看看的 内练一口气，外练一口屁。 爱护环境，人人有病。 如果有一双眼睛陪我一同哭泣，就值得我为生命受苦。 我的id是假冒的，大家不要相信我是骗子。 听君一席话，省我十本书!
页:
[1]