怎么进行web应用缓慢故障分析
本篇文章为大家展示了怎么进行web应用缓慢故障分析，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
朋友在一家购物网站做运维不久，今日打电话说前台页面打开比较慢订单无法正常投递，但是查看CPU使用率较低没什么压力，只是内存稍高86%左右，磁盘读写也很正常，咨询我怎么进行解决。我问了他一些基本的系统架构问题，知道是F5做的负载均衡分发到前端10台应用服务器上，中间件是JBOSS，后端数据库是ORACLE.整理了下思路，决定让朋友进行如下分析：
一、登陆前端应用服务器，首先查看统计ip连接数
[user@local ~]$ netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
1
1 Address
1 servers)
2 172.16.100.35
2 172.16.100.38
2 172.16.100.45
4 127.0.0.1
10 172.16.100.18
20 172.16.100.8
2048 172.16.100.98 #在服务器和负载均衡间有2048个连接
查看JBOSS应用端口8080的情况
[user@local ~]$ netstat -ntu |grep 8080
tcp 0 0 172.16.100.26:8080 172.16.100.98:19593 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:16777 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:11913 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:1929 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:53641 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:43401 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:36233 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:28040 TIME_WAIT
tcp 0 0 172.16.100.26:8080 172.16.100.98:5000 TIME_WAIT
...............................................................
...............................................................
...............................................................
[user@local ~]$ netstat -ntu |grep 8080|grep TIME_WAIT |wc -l
2003
通过以上内容显示，在前端应用服务器和负载均衡间产生了大量TCP等待，这正是消耗内存并把前台应用拖慢的主要原因。由负载均衡分发到应用服务器的大量请求可能由于JBOSS的处理瓶颈产生了等待，实际处理的请求远小于分发过来的请求。
二、查看JBOSS连接数设置
一般中间件jboss连接后端的oracle，在deploy下会有个文件oracle-ds.xml，我们看一下它连接数据库的代码：
注意：
三、查看ORACLE连接数设置
SQL>select count(*) from v$process --当前的连接数
显示为45
SQL>select value from v$parameter where name = 'processes' --数据库允许的最大连接数
显示为600
(注:当数据库最大连接数不够时会出现客户端连接间歇性失败，报错ORA-12519)
通过以上数据分析，在ORACLE端显示的连接数并没有体现出应有的压力，那么瓶颈在哪？应该是JBOSS上，JBOSS的连接池参数设置的太小，导致前端的请求卡在JBOSS处而不能正常通过JBOSS连接到后端ORACLE，从而导致前台应用缓慢订单不正常。
分析完毕后，告诉朋友增大JBOSS连接池参数，把
这一事例告诉我们，一个水管中间最细处往往决定了通过的水流量，我们在优化后端ORACLE数据库的同时也别忘了优化中间件的参数。
补充1、修改ORACLE最大连接数：
#修改oracle最大连接数:
alter system set processes = 1000 scope = spfile;
重启数据库:
shutdown immediate;
startup;
补充2、修改/etc/sysctl.conf文件
net.ipv4.tcp_max_tw_buckets = 3000
表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为 3000。此项参数可以控制TIME_WAIT套接字的最大数量，避免服务器被大量的TIME_WAIT套接字拖死。
上述内容就是怎么进行web应用缓慢故障分析，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。
