dbo.TempGetStateItemExclusive3 wielokrotnie wywoływana

Question

Prowadzę dochodzenie w sprawie problemu z naszą witryną, która korzysta z serwera SQL do zarządzania sesjami. Strona internetowa to webformy asp.net oparte na CMS z sitecore. Mamy ten sam kod w różnych środowiskach, np. Kontrola jakości, inscenizacja i produkcja.

W produkcji obserwujemy okresowo gwałtownie rosnące zużycie procesora, które nie wiąże się w żaden sposób z ruchem na serwer. Wraz z tym skokiem procesora widzimy odpowiedni skok w sieciowych we/wy.

Nasze oprogramowanie monitorujące nie rozróżnia ruchu do Internetu i ruchu na serwer bazy danych; jednak to, co widzimy na serwerze DB, to dosłownie setki połączeń na sekundę z dbo.TempGetStateItemExclusive3 w bazie danych sesji asp, wszystkie dla tego samego identyfikatora sesji i bez odpowiadającej ilości żądań stron przychodzących na serwery WWW.

Przy tym samym kodzie i konfiguracji po prostu nie widzimy takiego zachowania dla innych środowisk. Nie widzimy tego również dla innych identyfikatorów sesji, tylko tego konkretnego.

Usunięcie wiersza z bazy danych powoduje po prostu jego odtworzenie z tym samym identyfikatorem sesji.

UPDATE

znalazłem ten błąd w dzienniku zdarzeń:

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) 

Każdy jakieś pomysły jak duplikat identyfikator sesji może być ewentualnie próbowali być tworzone?

Answer 1

Wygląda raczej na problem SQL niż na Sitecore, co może być związane z nieprzebywaniem sesji. Nie jestem DBA, ale czy jest włączony Agent SQL? Czy twój produkcyjny serwer SQL na innym poziomie dodatku Service Pack/poprawki do innych środowisk (artykuł this wspomina o niektórych starych poprawkach dla podobnego problemu)?

Niektóre linki do sprawdzenia, aż może ktoś może odpowiedzieć na to bardziej szczegółowo! Możesz podać informacje o wersjach SQL, z których korzystasz.

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/

Answer 2

Aby zbadać tezę, że jest może być coś w konfiguracji aplikacji w IIS, można zrzucić config witryny internetowej przy użyciu Deploy (msdeploy). Następnie wykonaj porównanie na wyjściu między pudełkiem, w którym występuje problem, a innym, które tego nie robi.

Coś wyjście to pocieszyć

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

lub jako XML

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

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

Answer 3

Mamy do czynienia z podobnym problemem mającą następującą konfigurację:

• IIS 7.5
• .NET Framework 4.0
• Windows 2008 (zarówno na IIS i serwera DB)
• sesji zarządzanych przez bazę danych ASPState

Problemem było to, że czasami niektóre z sesji pozostał zamknięty do bazy ASPState, w wyniku setek połączeń na sekundę do dbo.TempGetStateItemExclusive3 dla każdej z zablokowanych sesji.

Procesor na serwerze IIS ostatecznie zwiększyłby liczbę zablokowanych sesji. Tymczasowym rozwiązaniem było odtworzenie puli aplikacji.

Idąc dalej i włączając śledzenie na serwerach IIS, a następnie analizując ślady zauważyliśmy, że kiedykolwiek wystąpił problem (np. Problem z połączeniem sieci, który spowodował błąd 500 serwera wewnętrznego) w module EXECUTE_REQUEST_HANDLER, następny moduł RELEASE_REQUEST_STATE (i powinien odblokować sesję) nie został wykonany. Tak więc sesja pozostała zamknięta.

Okazało się być to błąd z IIS i naprawiliśmy go zmieniając wartość UploadReadAheadSize 0 w pliku web.config:

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

Obiekt UploadReadAheadSize określa liczbę bajtów serwerze WWW odczyta bufor i przejdzie do rozszerzenia ISAPI. Dzieje się to raz na żądanie klienta.

Zobacz także: ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress