记一个由MemCached引发的性能问题

ienki

　　最近有个项目用loadrunner做了压力测试，发现并发量还不到200服务器就支撑不住了。boss那边紧急开会，说此项目最近3个月内将有100家中大型公司用于校园招聘工作，如果这个问题不解决公司有可能玩完。于是紧急动员，当晚重启压力测试，力争把问题解决。
　　由于之前测试部门做压力测试的时候我不在场，所以今天测试的时候先让他们演示的一遍，当loadrunner跑到100的时候，问题出来了，网站访问开始变慢，计数器webservice/current connections急剧上升，直到1000左右，这是访问网站报503错误。这一次我只是为了看下现象，我和小伙伴们都没有做任何处理。
　　在再次开启loadrunner之前，我和小伙伴们就早早各自做好了准备，有些添加计数器，观察计数器，期望可以看出端倪，而我比较喜欢windbg这个东西，因为她从来没欺骗过我，我相信这次也不例外。终于在并发达到100，网站抛出503的时候，我敲下了adplus，终于抓住了第一手资料。
　　下面一起来分析这个dump吧，首先我的思路是这样的，并发了只有100，但是已经拒绝服务，而且current connections竟然达到1000，说明iis处理不过来导致队列越来越长 ，超出了队列 允许的最大长度，所以抛出503，那为什么iis处理不过来呢，因为程序有问题，有某个地方成为了瓶颈，如果用windbg来看的话，应该大部分的线程都卡在了同一个地方。
　　首先打开windbg，选择抓到的dump文件
　　先加载sos.dll
　　0:000> .load  sos
　　再看看所有线程的clr堆栈，看看所有的线程运行到哪里了
　　0:000> ~* e !clrstack
　　-------------大部分的线程最后运行的程序出现了下面这段-----------------------
　　OS Thread Id: 0x32bc (65)
Child SP IP       Call Site
07ffe6b0 7c95845c [InlinedCallFrame: 07ffe6b0]
07ffe6ac 7a9f07ad DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
07ffe6b0 7a9994a2 [InlinedCallFrame: 07ffe6b0] System.Net.UnsafeNclNativeMethods+OSSOCK.recv(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
07ffe6f8 7a9994a2 System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags, System.Net.Sockets.SocketError ByRef)
07ffe730 09c8a654 Enyim.Caching.Memcached.PooledSocket+BasicNetworkStream.Read(Byte[], Int32, Int32)
07ffe754 7a1b9b31 System.IO.BufferedStream.Read(Byte[], Int32, Int32)
07ffe770 0556dcfe Enyim.Caching.Memcached.PooledSocket.Read(Byte[], Int32, Int32)
07ffe7b0 09c8a237 Enyim.Caching.Memcached.GetHelper.ReadItem(Enyim.Caching.Memcached.PooledSocket)
07ffe800 09c8969e Enyim.Caching.Memcached.GetOperation.ExecuteAction()
07ffe814 09c895ba Enyim.Caching.Memcached.Operation.Execute()
07ffe83c 09c894fc Enyim.Caching.MemcachedClient.Get(System.String)
07ffe86c 09c8948e MemcachedProviders.Cache.MemcachedCacheProvider.Get(System.String)
07ffe87c 09c83efc XXX.Caching.MemcachedCacheProvider.XXX.Caching.ICacheProvider.Get(System.String)
07ffe888 09c83d0a XXX.Caching.CacheManager.Get(System.String)
07ffe8b8 09c83c70 XXX.Caching.CacheManager.Get[[System.__Canon, mscorlib]](System.String)
　　..................这里省略若干行.................
　　这以为着什么，意味着MemCached成为了最后的执行点，成为了瓶颈，于是找来同事商量下，同事也认为极有可能，最后我们修改配置，改为启用。net自带的缓存 。
　　再次运行loadrunner，并发200毫无压力，增加到并发500，依然杠杠的。最后我们再看代码研究问题，一致认为是我们过分依赖MemCached，把所有能缓存的数据都放入了MemCached，大部分需要取数据的地方都经过了MemCached，MemCached成为了瓶颈，可笑吗，使用MemCached本来是希望提高性能的，结果倒成了瓶颈。
　　本文重点不在讨论问题，而在解决问题的方式。有一段时间没有用windbg了，有点生了，也许是该整理一下各种关于windbg的案例。这东西和正则一样，不用就忘。