Linux系统,问题定位
问题描述
网络电视台-红领巾之歌项目中,首页模块,100用户并发访问,发现应用服务器的带宽超过400mbps,大大超出现网环境百兆带宽要求,系统带宽性能不达标。
备注:测试环境拓扑图
图-1
原因分析
1. 通过Analysis打开LR测试结果,分析Windows Resources对IIS应用服务器的带宽监控数据(见图-2),可知应用服务器带宽不达标主要是接收带宽(流入的数据量)超过450mbps(45MB/s),发送带宽很小。应用服务器收到大量数据导致带宽瓶颈。
图-2(单位MByte/s,绿线为接收带宽,红线为发送带宽)
2. 由图-1测试环境拓扑结构可知,IIS应用服务器收到的数据可能来自三个部分:用户PC、文件接收站、数据库/redis服务器。分析上述三个部分传给IIS应用服务器的数据量大小:
l 用户PC,就是测试中的LR负载机,负载机发送给IIS应用服务器的数据就LR脚本中的3个http请求(采用httpwatch分析可得到3个请求的数据量约5KB),100用户并发测试所产生的请求流量约500KB=0.5MB。可知负载机对应用服务器请求产生的流量不是带宽瓶颈的原因。
l 根据LR测试结果Windows Resources(见图-3),可知文件接收站往应用服务器发生的流量约8.5KB=0.008MB。可知文件接收站对应用服务器的流量不是带宽瓶颈的原因。
图-3(单位MByte/s,蓝线为发送带宽)
l 打开对数据库/redis服务器的nmon监控结果,分析NET数据(见图-4),可知测试过程中该服务器平均每秒往IIS应用服务器发送约45000KB=45MB数据量,该数值和IIS应用服务器接收带宽基本一致,即可判断数据库/redis服务器产生的流量是造成应用服务器带宽瓶颈的原因。
图-4
3. 因为数据库/redis服务器上同时部署mysql数据库服务和redis缓存服务,IIS应用服务器和这两个服务均存在数据交互。为定位是哪一个服务产生大流量的数据,采用dump抓包工具分析数据库(3309端口)和redis服务(6379端口)产生的流量。抓包可知,单用户访问首页,redis服务给应用服务器返回约3MB的数据量,数据库返回的数据量很小。故可判断应用服务器带宽瓶颈是linux服务器上的redis服务返回数据量太大导致。
4. 打开抓包文件20120803_redis.dmp,分析可知该文件内包含系统所有注册用户的信息(users表),活动动态中的文章信息、媒体报道信息等。这些数据有很大部分是用户访问首页不需要知道的。
dump相关参考命令:
time tcpdump -i eth0 -s 1500 dst host 192.168.19.34 and src port 3309 -s 0 -w 20120803_mysql.dmp
time tcpdump -i eth0 -s 1500 dst host 192.168.19.34 and src port 6379 -s 0 -w 20120803_redis.dmp