数据库|mysql教程
云计算,之路,阿里,超级,怪黑色,10秒钟
数据库-mysql教程
监控app 源码下载,ubuntu连接光猫,tomcat9会快吗,爬虫获取数据网站,如何用php代码解析千图,崇左seo公司lzw
自从5月24日发布博文(云计算之路-阿里云上:两个重要突破)之后,情况有了明显改善。但是我们不但没有丝毫的放松,反而变得更加艰苦。我们被一个非常非常奇怪的问题所困扰,这段时间我们与阿里云一起在努力与之作艰苦斗争。 这个问题每天会出现十几次,每次
源码 手机,vscode背景钢铁侠,ubuntu淘宝源,tomcat优化体系,sqlite编辑后不识别,视频爬虫软件合法吗安全吗,php 银联支付接口,钦州seo站内优化,jeecms网站群介绍,asp网页发送邮件,如何查看模板文件路径lzw
微信在线插件源码下载,ubuntu cuda简书,war包部署在tomcat哪里,爬虫系列皮肤,php数据库学习教程,seo实战演练lzw
自从5月24日发布博文(云计算之路-阿里云上:两个重要突破)之后,情况有了明显改善。但是我们不但没有丝毫的放松,反而变得更加艰苦。我们被一个非常非常奇怪的问题所困扰,这段时间我们与阿里云一起在努力与之作艰苦斗争。
这个问题每天会出现十几次,每次出现都会持续10秒钟(“黑色10秒钟”由此而来)。
为了更清楚地表达问题,大家先看一张IIS处理请求的流程图(注:问题不是来自IIS,而是通过IIS定位出问题)。
(注:这张图对理解我们遇到的问题很重要)
问题现象一:出现问题时,在Windows性能监视器中的表现如下:
上图中绿色线条表示的是Web Service->Current Connections(Web Service就是第一张图中的World Wide Web Pulishing Service),出现问题时Current Connections会突然跳上去(通常会跳到200以上)。我们猜测这是瞬间的高并发请求引起的。(这种瞬间高并发请求在压力测试中很难模拟,所以我们一直未能通过压力测试重现这个问题)
上图中棕色线条表示的是 Applications->Requests/s,在出问题时这个值会变为0,服务器空间,也就是没处理任何请求。而且->Requests Queued与Requests Current也都为0,说明不仅没有处理请求,可能根本没收到请求。
上图中蓝色线条表示的是TCPv4->Connections Established,虚拟主机,出现问题时这个值也会飚上去,通常在1000以上,它稍稍滞后于Current Connections的上升。
上图中红色线条表示的是% Processor Time,出现问题时,Requests/s为0,但CPU却没有明显下降(本来绝大部分CPU占用都消耗在处理请求上)。这就是问题最奇特的地方,CPU被占用了,却什么活也没干。
问题现象二:在问题期间,IIS的http.sys能正常接收请求,但不响应请求,等到“黑色10秒钟”之后才响应累积的请求。
1. 在禁用Output Caching的情况下,“黑色10秒钟”期间的IIS日志显示IIS没有对任何请求进行响应。等到“黑色10秒钟”一过,会出现time-taken为10s, 9s, 8s…这样的请求,这些请求恰恰是在“黑色10秒钟”期间收到的,只是在“黑色10秒钟”之后才进行响应。
2. 如果开启Output Caching,会在IIS日志中看到“黑色10秒钟”期间IIS会正常响应一些静态文件。实际上这些静态文件是http.sys通过Kernel-Mode caching返回的。这说明在问题期间,http.sys是正常的。
问题现象三:在问题期间,应用程序没收到任何请求。
我们在应用程序中记录了访问日志,发现在“黑色10秒钟”期间应用程序也没有收到请求,确认了根本没收到请求,也就是说请求可能没有进入到w3wp进程(应用程序池我们用的是集成模式)。
综合上面的三个现象,我们可以分析出,在“黑色10秒钟”期间http.sys正常,请求没有到达w3wp进程。问题肯定出在http.sys->w3wp之间的某个环节。
再来看一下IIS请求处理流程图:
从图中可以知道,在http.sys->w3wp之间还有WWW service与WAS。而在性能监视器中显示“黑色10秒钟”期间WWW service的Current Connections的值是跳高的,说明WWW service也收到了请求。所以剩下的最大的嫌疑对像就是WAS。而WAS的主要任务就是将请求转发给对应的w3wp,如果它出问题了,w3wp自然收不到请求。
WAS resides in User Layer of IIS. It takes the request from HTTP.SYS and pass it to the respective application pool.
在之前我们走了很多很多弯路,但当我们把焦点放在WAS上,就开辟了一条最有希望的问题解决之路。
我们在Web服务器上通过Process Explorer拿到WAS进程的堆栈信息:
通过堆栈信息,我们发现WAS进程都会等SpinLock,当时我们一看到SpinLock眼前就一亮。因为之前阿里云技术人员问过我们有没有在应用程序中使用SpinLock,美国服务器,说SpinLock在虚拟机上可能会引发CPU空转(在物理机上没这个问题),虽然我们没有在应用程序中使用SpinLock,但是在WAS中用到了,而且是在Windows内核级别。
我们之前提到过在“黑色10秒钟”期间CPU占用没有明显下降(CPU被占用却不干活)的奇特现象如果用CPU空转来解决,简直是完美无缺。
在眼前一亮之后,我们意识到这是非常耀眼的一亮,一定要深挖下去。
SpinLock是在Windows内核级别使用了,而Windows内核出问题的可能性比虚拟机(阿里云用的是Xen)出问题的可能性要小很多很多。所以我们把嫌疑对象放在了Xen上。
在网上找到了两个重要的线索:
1. Kernel lockup running 3.0.0 and 3.2.0 on multiple EC2 instance types
Running lots of threads which utilize spinlocks, we hit a stage where the spinlock is still locked but none of the CPUs seem to be actively holding it.
注:“黑色10秒钟”期间的瞬时高并发请求会造成lots of threads。
2. xen: Send spinlock IPI to all waiters
There is a loophole between Xen’s current implementation of pv-spinlocks and the scheduler.
注:Xen在处理spinlock时的确存在bug。
从这两个线索中,我们可以作出这样的假设——“黑色10秒钟”很可能是Xen的bug引起的,接下来要做的就是证明这个假设。
这就是我们发这篇博客时的当前局面,已经完全不一样了,从大海捞针变为做证明题。
阿里云会准备一台安装最新版Linux+最新版Xen的虚拟机以验证问题是否依然存在。
我们准备从Xen的spinlock.c源代码中找出为什么每次都是10秒的证据。
spinlock.c源代码详见:
根据Kernel lockup running 3.0.0 and 3.2.0 on multiple EC2 instance types一文中的调用堆栈:
目前我们初步判断“10秒钟”可能发生在调用xen_proll_irq_timeout时,源代码见。
在Xen的源代码中找出“10秒钟”的来源不知要花多少时间,所以先写了这篇博文把当前的情况向大家汇报一下——我们与阿里云一直在努力解决问题。
如果觉得《云计算之路-阿里云上:超级奇怪的“黑色10秒钟”》对你有帮助,请点赞、收藏,并留下你的观点哦!