我正在調查我們的網站使用SQL Server來管理會話的問題。該網站是基於sitecore CMS的asp.net webforms。我們在各種環境中具有相同的代碼,例如質量保證,分期和生產。dbo.TempGetStateItemExclusive3重複調用
在生產中,我們看到的是,我們週期性地發現CPU使用率快速上升,這與使用服務器的流量無關。隨着CPU的高峯,我們看到了網絡I/O的相應峯值。
我們的監控軟件不區分流量到互聯網的流量和流量到數據庫服務器;然而,我們在數據庫服務器上看到的數字是,在asp會話數據庫中,每秒數百次呼叫到dbo.TempGetStateItemExclusive3
,全部用於相同的會話ID,並且沒有相應數量的頁面請求進入Web服務器。
使用相同的代碼和配置,我們根本看不到其他環境的這種行爲。我們也沒有看到它的其他會議ID,只是這一個具體的。
從數據庫中刪除該行只會導致它使用相同的會話ID重新創建。
UPDATE
我發現在事件日誌中此錯誤:
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)
任何人都可以創建如何重複會話ID可能被嘗試任何想法?
你已經能夠看到這些多久尖峯模式通常最後,它們出現的頻率,和/或它們出現一天中什麼時間? – jadarnel27 2013-03-22 15:46:42
這只是一種在黑暗中拍攝而已,但是您的應用程序池是否在不同環境之間配置(顯着)不同?我想知道是否大量數據庫調用與生產應用程序池的某種預定/定期循環(應用程序池重置,並且ASP.NET運行時一次從SQL Server恢復所有未過期的會話) 。 – jadarnel27 2013-03-22 16:15:58
尖峯持續到應用程序池被回收爲止。這通常會在一段時間內解決問題。他們似乎沒有真正的模式隨機發生。我們以前在每天的預定時間都有應用程序池回收,但我們必須每隔2小時更改一次,以嘗試緩解此問題。如果有幫助,我們有2個Web前端服務器使用粘性會話進行負載均衡。我們的ISP技術人員告訴我們,LB上沒有相應的流量進入,所以它就像一些失控的線程正在進行這些調用。 – 2013-03-22 16:32:17