asp.net Web服务的CPU使用率高 [英] asp.net web-service high CPU usage

问题描述

我对网络服务有很奇怪的问题。设置如下：在IIS7（win2008）下的x64单核，1gb ram计算机上部署6个Web服务，每个Web服务都在专用的应用程序池中运行。 Web服务通过LB连接到mysql集群。我们使用的是mysql odbc连接器5.1.6，连接池关闭了.net v3.5。构建目标平台x64。
大约每3个小时，一个Web服务就会开始消耗100％的CPU（或者更佳地说是100％的CPU核心，但是由于它是单核计算机，因此它将占用100％的CPU）。同时mysql服务器处于空闲状态。从任务管理器中杀死挂起的w3wp并没有帮助，IIS重新启动会有所帮助。我正在查看进程浏览器，并在w3wp中看到一个带有以下堆栈跟踪的奇怪线程，我无法理解：

I have very weird problem with web-services. Setup is following: 6 web-services deployed on a x64 single core, 1gb ram machine under IIS7 (win2008), each running in a dedicated application pool. Web-services are connecting via LB to a mysql cluster. We are using mysql odbc connector 5.1.6 with connection pooling off, .net v3.5. Build target platform x64. Roughly, every 3hrs, one web-service starts consuming 100% of CPU (or better to say 100% of CPU core, but since it is a single core machine it will be 100% of CPU). At the same time mysql servers are idle. Killing "hanging" w3wp from task manager doesn't help, IIS restart helps. I'm looking at process explorer and see one strange thread inside w3wp with following stack trace, which i can't understand:

ntoskrnl.exe!IoAcquireRemoveLockEx+0xe7
ntoskrnl.exe!memset+0x22a
ntoskrnl.exe!KeWaitForSingleObject+0x2cb
ntoskrnl.exe!KeDetachProcess+0x120d
ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x3a3
ntoskrnl.exe!CcSetDirtyPinnedData+0x433
myodbc5.dll!SQLTablePrivilegesW+0x22dac
myodbc5.dll!SQLTablePrivilegesW+0x2bffd
myodbc5.dll!SQLTablePrivilegesW+0x107ea
odbc32.dll!SQLAllocHandle+0xba5
odbc32.dll!SQLAllocHandle+0x9c8
mscorwks.dll!IEE+0xa913
System.Data.ni.dll+0x56f8c3
System.Data.ni.dll+0x5c1efe
mscorwks.dll!IEE+0xb0ee
mscorwks.dll!CompareAssemblyIdentity+0x2bb8f
mscorwks.dll!CompareAssemblyIdentity+0x39deb
mscorwks.dll!CompareAssemblyIdentity+0xe63d
mscorwks.dll!CertCreateAuthenticodeLicense+0x21b12f
mscorwks.dll!StrongNameTokenFromPublicKey+0x49f7
mscorwks.dll!PreBindAssembly+0x88a46
mscorlib.ni.dll+0x3988d0
mscorlib.ni.dll+0x39877a
mscorwks.dll!IEE+0xb042
mscorwks.dll!CompareAssemblyIdentity+0x2610d
mscorwks.dll!CompareAssemblyIdentity+0x26358
mscorwks.dll!CompareAssemblyIdentity+0x2ae50
mscorwks.dll!CompareAssemblyIdentity+0x97ad7
mscorwks.dll!CompareAssemblyIdentity+0x97877
mscorwks.dll!CopyPDBs+0x170f3
mscorwks.dll!InitializeFusion+0x5994
mscorwks.dll!GetMetaDataInternalInterfaceFromPublic+0x34ad9
mscorwks.dll!InitializeFusion+0x1282d
mscorwks.dll!CorExitProcess+0x802d
mscorwks.dll!InitializeFusion+0xb5db
mscorwks.dll!CertCreateAuthenticodeLicense+0x240021
mscorwks.dll!CompareAssemblyIdentity+0x97bcc
mscorwks.dll!CompareAssemblyIdentity+0x97877
mscorwks.dll!CreateAssemblyNameObject+0x2c29d
mscorwks.dll!InitializeFusion+0x5994
mscorwks.dll!GetMetaDataInternalInterfaceFromPublic+0x34ad9
mscorwks.dll!InitializeFusion+0x1282d
mscorwks.dll!StrongNameErrorInfo+0x130fe
mscorwks.dll!InitializeFusion+0xbf48
mscorwks.dll!StrongNameErrorInfo+0x76b0
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21

我还能够在另一台计算机上重现同样的问题已部署VS2010并能够附加到挂起的w3wp上，并看到GC终结器线程正与类似于以下内容的stacktrace一起坐：

I was also able to reproduce the same problem on the other machine which has VS2010 deployed and was able to attach to "hanging" w3wp and saw that GC finalizer thread is sitting with a stacktrace similar to the one below:

[Native to Managed Transition]
System.Data.dll!System.Data.Odbc.OdbcHandle.ReleaseHandle()
[Native to Managed Transition]
[Managed to Native Transition]
mscorlib.dll!System.Runtime.InteropServices.SafeHandle.Dispose(bool disposing)
mscorlib.dll!System.Runtime.InteropServices.SafeHandle.Finalize()
[Appdomain Transition]

另外还有一个堆栈跟踪，我认为这反映了最后一个堆栈跟踪。 / p>

And one more stacktrace exists, which I believe is a reflection of the first one at the end.

my_SQLFreeStmtExtended  strmov  Highest
myodbc5.dll!strmov(char * dst, const char * src)  Line 38 + 0xd bytes    
myodbc5.dll!cli_safe_read(st_mysql * mysql)  Line 731    
myodbc5.dll!cli_read_query_result(st_mysql * mysql)  Line 2739 + 0x8 bytes   
myodbc5.dll!mysql_next_result(st_mysql * mysql)  Line 5221 + 0xd bytes   
myodbc5.dll!my_SQLFreeStmtExtended(void * hstmt, unsigned short fOption, unsigned int clearAllResults)  Line 427 + 0xc bytes     
odbc32.dll!000007fef1d43ee9()    
[Frames below may be incorrect and/or missing, no symbols loaded for odbc32.dll]     
odbc32.dll!000007fef1d43d3e()    
mscorwks.dll!000007fef102cd27()
System.Data.ni.dll!000007feebe73ad3() 

显然，在生产16核的计算机上也可以重现此问题。
我们已经在可能关闭连接或未处置的地方执行了代码检查和固定/重新编写代码。
对于这个问题，我将不胜感激，并接受其他建议，以供参考。

This problem obviously is also reproducible on production 16 cores machines. We have performed code review and fixed/re-wrote code in a places where we potentially could have left connection not closed and not disposed. I'll appreciate any help with this issue and accept any advice at what else i can look at.

推荐答案

我们决定开始使用mysql连接器.net代替mysql连接器odbc。我们所做的只是从OdbcConnection更改为MySqlConnection，从OdbcCommand更改为MySqlCommand，从OdbcParameter更改为MySqlParameter。我们对其进行了几次加速测试，看起来不仅获得了稳定性，而且还提高了性能。
因此，作为结论：使用MySql Connector .NET代替MySql Connector ODBC。

We've decided to start using mysql connector .net instead of mysql connector odbc. All we did is changed from OdbcConnection to MySqlConnection, from OdbcCommand to MySqlCommand, from OdbcParameter to MySqlParameter. We ran couple of ramp up tests against it and it looks like we gained not only stability but also improved performance. So, as a conclusion: use MySql Connector .NET instead of MySql Connector ODBC.

这篇关于asp.net Web服务的CPU使用率高的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！