189 8069 5689

怎么进行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,我们看一下它连接数据库的代码:

    jdbc/TETD

    jdbc:oracle:thin:@172.16.100.18:1521:orcl

    oracle.jdbc.driver.OracleDriver

    TETD_QT

    Hpoui&bmn$m#e$m_n20uytwe@iil

        20

        50

    org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter 

 注意:的值设的是20,设的值是50

三、查看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连接池参数,把调整为200,调整为500.后来朋友调整了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应用缓慢故障分析,你们学到知识或技能了吗?如果还想学到更多技能或者丰富自己的知识储备,欢迎关注创新互联行业资讯频道。


网页名称:怎么进行web应用缓慢故障分析
浏览路径:http://cdxtjz.com/article/jjooig.html

其他资讯