Chinaunix首页 | 论坛 | 博客
  • 博客访问: 140660
  • 博文数量: 12
  • 博客积分: 45
  • 博客等级: 民兵
  • 技术积分: 194
  • 用 户 组: 普通用户
  • 注册时间: 2012-11-03 13:16
文章分类

全部博文(12)

文章存档

2015年(3)

2014年(8)

2013年(1)

分类: 系统运维

2014-02-14 22:32:23

背景
上周业务方反馈说访问兄弟部门的一个接口超时量突然增加,看监控视图,占比大概5~10%左右。

我登录idc机器curl构造请求测试正常,无延时。对方特意提供了内网vip给我们测试,业务开发修改发布后发现还是有延时。接口方给出延时监控视图,最大延时,如下图:


这个视图只能说明建立连接成功的请求状况,但现在双方都说服不了对方。开发甚至认为是机器环境有问题,要求运维查清楚。

苦逼的取证过程
我重新用curl构造请求测试了内网vip、外网vip,发现都正常,直接curl 也是ok的。说明网络没问题,那问题出在接口方。能否模拟server那样大并发请求验证下呢?顺手写了个简单的python脚本并发请求接口:

  1. import urllib2
  2. from multiprocessing import Pool

  3. def worker(id):
  4.     while id:
  5.         try:
  6.             headers={"Host": 'view.inews.xxoo.com', 'User-agent':'Mozilla/5.0 (Linux i686)'}
  7.             req=urllib2.Request('',None,headers)
  8.             reqcode=urllib2.urlopen(req).code
  9.             #reqcode=urllib2.urlopen('http:///').code
  10.             return reqcode
  11.         except:
  12.             return None


  13. if __name__ == '__main__':
  14.     pool = Pool(4)
  15.     print pool.map(worker, range(1,20))
  16.     pool.close()
  17.     pool.join()
测试内网vip,第一次跑脚本ok,但第二次就出现connect timeout:

但是测试是ok的!!
联系业务开发和接口方,继续strace 跟踪脚本连接:

这个结果就比较清晰了,像是syn包直接被丢掉了。
后来,接口方的运维查到原因是lvs后的一台rs没有回包,但lvs oss系统没有及时剔除掉有问题的机器。
阅读(3398) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~