云计算之路-阿里云上:拔云见日的那一刻,热泪盈眶

当用路过秋天的压力测试工具重现问题的那一刻,热泪盈眶!这段时间所承受的一切一涌而出。。。

下面这张图是首次压力测试重现问题时的Windows性能监视器截图,我们对这样的图太熟悉了,当它一出现,就知道问题重现了。红色的直线表示的是100%的CPU占用率,蓝色如栅栏的线条是ASP.NET请求执行时间(Request Execution Time)。这时如果用浏览器访问站点,会奇慢无比。

我们是这样进行压力测试的,将一台Web服务器从阿里云SLB(负载均衡)中摘下来,其他运行环境(Web程序、Memcached、NoSQL、RDS)没有任何变化,然后用压力测试直接向这台Web服务发出请求。压力测试工具造成这台云服务器的TCPv4->Connections Established(性能监视器的一个监测指标)超过2000,问题立即重现。

TCPv4->Connections Established这个指标在我们之前的博文中从没提过,而它就是今天取得突破的关键所在。简单来说,它表示的是这台服务器的当前TCP连接负载。今天下午我们发现,正常期间Connections Established的数值都在1000以内,而故障期间这个值都会超过1000。在出现故障的时候,只要我们以某种方式将Connections Established的数值降到1000以下,故障就会消失,比如重启IIS、禁用网卡,甚至重启Memached/NoSQL服务器(它们与Web服务器之间进行频繁的TCP连接)也能解决问题。

我们的压力测试就是针对TCPv4->Connections Established,只要压到1000以上,问题就会重现;降到1000以下,问题就会消失。(另一张压测截图

为了进一步验证是这台云服务器本身的问题,与周边环境无关。在压测时这台云服务器CPU 100%、访问奇慢无比期间,我们访问处于同样环境的其他云服务器,速度飞快。

根据压测情况,我们的猜测是:在某种特定的条件下,当云服务器(Xen虚拟机)的并发TCP连接数超过一定的数值(目前我们的估计是1000~2000),云服务器的CPU占用率会飙升或大幅波动,某些处理能力会急剧下降,比如ASP.NET的请求处理时间由“几十毫秒”狂飚至“几十秒”。(仅是我们单方面的猜测,并不代表阿里云云服务器的真实情况)

那我们是如何找到TCPv4->Connections Established的呢?

这要从今天凌晨4点多路过秋天对我们的站点进行短暂的压测说起。压测之后,我们发现不仅4台8核的Web服务器的CPU没撑住,竟然连8核的Memcached服务器的CPU也没撑住。这说明问题与应用程序没有关系,如果是应用程序的原因,那不应该出现Memcached服务器CPU撑不住的情况。应用程序与Memcached软件(Couchbase)都会引起这个问题的可能性估计一万看才会遇到一次。所以从这个压测,我们进一步排除ASP.NET应用程序引起这个问题的可能性。

今天上午故障期间,我们特地禁用Memcached/NoSQL进行观察,问题仍旧。进一步排除了Memcached/NoSQL引起这个问题的可能性。问题与虚拟机的CPU占用高有关,这是板上钉钉的事实,但是究竟什么触发了CPU占用高比这个事实更重要。CPU不会喝酒喝多了,不会发羊癫疯。。。肯定是某个因素造成的。

IIS并发连接数是一个嫌疑对象,但很难确定是因为CPU占用高造成IIS并发连接数上升,还是因为IIS并发连接数上升造成CPU占用高。在下午的故障期间,我们发现重启Memcached/NoSQL竟然也能解决问题,说明问题即使与IIS并发连接数有关,但也不是仅与IIS并发连接数有关。

后来,我们在网上找到了一些说Xen虚拟机TCP处理能力可能存在问题的线索(这只是启发我们思考问题的线索,不代表现在的Xen虚拟机还存在这个问题)。于是,我们把虚拟机的TCP处理能力作为一个怀疑对象,并在Windows性能监视器中找到一个监测指标——TCPv4->Connections Established,在下午故障期间特地监测了这个指标,才发现前面所说的Connections Established在1000以下一切正常,1000以上就出故障。然后在压力测试中专门针对这项指标进行测试,才重现了问题。

那如何解决这个问题?

从我们自身角度,我们会想办法尽量减少单台云服务器的TCPv4->Connections Established,究竟什么办法是有效的,需要经过明天访问高峰期的验证。

。。。

热泪盈眶的不仅仅是因为在煎熬中看到了曙光,更是因为给大家带来这么多这么大的麻烦,总算有了一点交代。

彻底解决这个问题后,我们会以更好的产品、更好的服务去弥补!

posted @ 2013-05-22 22:04 博客园团队 阅读(...) 评论(...) 编辑 收藏