веб-сервис asp.net высокая загрузка процессора - PullRequest
Новая
       6

веб-сервис asp.net высокая загрузка процессора

0 голосов
/ 21 декабря 2011

У меня очень странная проблема с веб-сервисами. Настройка следующая: 6 веб-служб развернуты на одноядерном компьютере x64, оперативной памяти 1 ГБ под IIS7 (win2008), каждая из которых работает в выделенном пуле приложений. Веб-сервисы подключаются через LB к кластеру mysql. Мы используем mysql odbc соединитель 5.1.6 с отключенным пулом соединений .net v3.5. Сборка целевой платформы x64. Примерно каждые 3 часа один веб-сервис начинает потреблять 100% процессорного времени (или, лучше сказать, 100% процессорного ядра, но, поскольку это одноядерный компьютер, он будет составлять 100% процессорного времени). В то же время серверы MySQL простаивают. Убийство "зависания" w3wp из диспетчера задач не помогает, перезапуск IIS помогает. Я смотрю на Process Explorer и вижу один странный поток внутри w3wp со следующей трассировкой стека, которую я не могу понять: 

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 сидит со стековой трассировкой, аналогичной приведенной ниже: 

[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]

И существует еще одна трассировка стека, которая, я считаю, является отражением первой в конце. 

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-ядерных станках. Мы провели проверку кода и исправили / переписали код в местах, где мы могли бы оставить соединение не закрытым и не уничтоженным. Я буду признателен за любую помощь в этом вопросе и приму любой совет, что еще я могу посмотреть.

Ответы [ 2 ]

0 голосов
/ 24 декабря 2011

Мы решили начать использовать MySQL-коннектор .net вместо mysql-коннектора odbc. Все, что мы сделали, это изменили с OdbcConnection на MySqlConnection, с OdbcCommand на MySqlCommand, с OdbcParameter на MySqlParameter. Мы провели несколько тестов на повышение производительности, и, похоже, мы приобрели не только стабильность, но и улучшенную производительность. Итак, в заключение: используйте MySql Connector .NET вместо MySql Connector ODBC.

0 голосов
/ 21 декабря 2011

Если вы этого еще не сделали, вы можете отменить бесплатную пробную версию Redgate Ants Performance Profiler : если в вашем коде есть какие-либо узкие места, незащищенное соединение или что-то подобное, это должно точно сказать вамгде.Просто удалите его, когда закончите.

Это может быть более полезным, чем трассировка стека:)

Надеюсь, это поможет - удачи!

...