Dbo.TempGetStateItemExclusive3 вызывается многократно

Я изучаю проблему с нашим сайтом, который использует SQL-сервер для управления сеансами. Веб-сайт - это веб-формы asp.net, основанные на CMS sitecore. У нас есть тот же код в разных средах, например. QA, постановка и производство.

В производстве, что мы видим, периодически мы получаем быстро растущее использование ЦП, которое никак не коррелирует с трафиком на сервер. Наряду с этим пиком CPU мы видим соответствующий всплеск сетевого ввода-вывода.

Наше программное обеспечение для мониторинга не проводит различия между трафиком в Интернете и трафиком на сервер БД; однако то, что мы видим на сервере БД, составляет буквально сотни вызовов в секунду до dbo.TempGetStateItemExclusive3 в базе данных сеанса asp, все для одного и того же идентификатора сеанса, и никакое соответствующее количество запросов страниц, поступающих в веб-серверов.

С тем же кодом и конфигурацией мы просто не видим этого поведения для других сред. Мы также не видим его для других идентификаторов сеансов, только для этого конкретного.

Удаление строки из базы данных просто приводит к ее воссозданию с тем же идентификатором сеанса.

ОБНОВЛЕНИЕ

Я нашел эту ошибку в журнале событий:

Violation of PRIMARY KEY constraint 'PK__ASPState__C9F49290145C0A3F'. Cannot insert duplicate key in object 'dbo.ASPStateTempSessions'. The duplicate key value is (sessionidwiththeproblem). The statement has been terminated.
Stack trace:

at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean\ breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand\ cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler,\ TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds,\ RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior,\ RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior,\ RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult\ result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at System.Web.SessionState.SqlSessionStateStore.SqlExecuteNonQueryWithRetry(SqlCommand\ cmd, Boolean ignoreInsertPKException, String id)

Любые идеи о том, как можно было бы создать дублирующийся идентификатор сеанса?

Ответ 1

Мы столкнулись с аналогичной проблемой, имеющей следующую конфигурацию:

IIS 7.5
.NET Framework 4.0
Windows 2008 (как на IIS, так и на сервере БД)
сеансы, управляемые базой данных ASPState

Проблема заключалась в том, что иногда некоторые из сеансов оставались заблокированными в базе данных ASPState, что приводило к сотням вызовов в секунду для dbo.TempGetStateItemExclusive3 для каждой из заблокированных сеансов.

Процессор на сервере IIS в конечном итоге увеличит количество заблокированных сеансов. Временным решением было переработать пул приложений.

Идем дальше и включаем трассировку на серверах IIS, а затем анализируем отслеживаемые нами следы, когда всякий раз, когда была проблема (например, проблема сетевого подключения, вызвавшая ошибку внутреннего сервера 500) в модуле EXECUTE_REQUEST_HANDLER, следующий модуль который RELEASE_REQUEST_STATE (и должен разблокировать сеанс) не был выполнен. Таким образом, сеанс остался заблокированным.

Он оказался ошибкой от IIS, и мы исправили его, изменив значение uploadReadAheadSize на 0 в файле web.config:

<system.webServer>
  <serverRuntime uploadReadAheadSize="0" />
</system.webServer>

Свойство UploadReadAheadSize устанавливает количество байтов, которые веб-сервер считывает в буфер, и переходит к расширению ISAPI. Это происходит один раз на запрос клиента.

См. также: ManagedPipelineHandler для AJAX POST падает, если пользователь IE9 перемещается в сторону от страницы во время выполнения этого вызова

Ответ 2

Похоже на проблему SQL, а не на Sitecore, возможно, связанную с тем, что сеансы не очищаются. Я не администратор базы данных, но агент SQL включен? Является ли ваш производственный SQL-сервер на другом уровне пакета обновления/патча другим средам (в этой статье упоминаются некоторые старые исправления для аналогичной проблемы)?

Некоторые ссылки для расследования, пока кто-то не сможет ответить на это более конкретно! Возможно, вы захотите включить некоторую информацию о том, какие версии SQL вы используете.

http://jerschneid.blogspot.co.uk/2010/01/aspnet-sql-server-requests-timing-out.html

https://www.simple-talk.com/sql/sql-tools/how-to-identify-blocking-problems-with-sql-profiler/

Ответ 3

Чтобы изучить понятие, которое может быть что-то в настройке приложения в IIS, вы можете сбросить конфигурацию своего сайта с помощью веб-развертывания (msdeploy). Затем выполните сравнение на выходе между полем, в котором отображается проблема, а другая - нет.

Что-то вроде этого выведет на консоль

msdeploy –verb:dump –source:appHostConfig="Default Web Site"

или как XML

msdeploy –verb:dump –source:appHostConfig="Default Web Site" -xml

См. http://technet.microsoft.com/en-us/library/dd569101(v=ws.10).aspx