2013-03-22 93 views
11

我正在調查我們的網站使用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可能被嘗試任何想法?

+0

你已經能夠看到這些多久尖峯模式通常最後,它們出現的頻率,和/或它們出現一天中什麼時間? – jadarnel27 2013-03-22 15:46:42

+0

這只是一種在黑暗中拍攝而已,但是您的應用程序池是否在不同環境之間配置(顯着)不同?我想知道是否大量數據庫調用與生產應用程序池的某種預定/定期循環(應用程序池重置,並且ASP.NET運行時一次從SQL Server恢復所有未過期的會話) 。 – jadarnel27 2013-03-22 16:15:58

+0

尖峯持續到應用程序池被回收爲止。這通常會在一段時間內解決問題。他們似乎沒有真正的模式隨機發生。我們以前在每天的預定時間都有應用程序池回收,但我們必須每隔2小時更改一次,以嘗試緩解此問題。如果有幫助,我們有2個Web前端服務器使用粘性會話進行負載均衡。我們的ISP技術人員告訴我們,LB上沒有相應的流量進入,所以它就像一些失控的線程正在進行這些調用。 – 2013-03-22 16:32:17

回答

0

看起來像一個SQL問題,而不是一個Sitecore之一,可能與會議沒有被清理。我不是DBA,而是啓用了SQL代理?您的生產SQL服務器與其他環境的服務包/補丁級別不同(this文章提到了一些針對類似問題的舊修補程序)?

一些調查的鏈接,直到有人可以更具體地回答這個問題!您可能想要包含您正在使用的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/

+0

感謝您的輸入,是的SQL代理正在運行,清理作業正常運行。 sessionstate表中可能有400行,DB大約爲15 MB。 – 2013-03-22 16:27:40

0

探討是可以在IIS中的應用程序設置的東西的概念,你可以放棄了使用Web部署(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

7

我們面臨一種具有下述構成一個類似的問題:

  • IIS 7.5
  • .NET Framework 4。0
  • 的Windows 2008(在IIS和數據庫服務器兩者)
  • 會議由ASPState的數據庫

的問題是,有時某些會議的仍然鎖定在ASPState的數據庫管理,造成數百對每個鎖定會話每秒調用dbo.TempGetStateItemExclusive3。

IIS服務器上的CPU最終會隨着鎖定會話的數量而增加。臨時解決方案是回收應用程序池。

繼續並在IIS服務器上啓用跟蹤,然後分析跟蹤,我們注意到,只要在EXECUTE_REQUEST_HANDLER模塊中出現問題(即導致500內部服務器錯誤的網絡連接問題),下一個不會執行RELEASE_REQUEST_STATE模塊(並且應解鎖會話)。因此會議仍然鎖定。

它打開了從IIS中的錯誤,我們通過在web.config中應將UploadReadAheadSize的值更改爲0固定它:

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

的應將UploadReadAheadSize屬性建立字節的Web服務器的數量將讀入緩衝區並傳遞給ISAPI擴展。這發生在每個客戶端請求一次。

參見: ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress

+0

我們在生產中看到了同樣的問題,正在考慮使用您找到的解決方案。儘管如此,我並不熟悉該財產,但我無法找到任何有關在網站的任何其他部分更改它的效果的任何信息。你能否提供更多關於將其設置爲0的其他效果的更多細節? – Geneb 2015-11-12 22:28:02

+0

哪個是'SQL語句'查看**會話保持鎖定**到_ASPState數據庫_中?如何**監控** _每秒調用數百次_:SQL事件探查器或其他軟件? – Kiquenet 2016-10-28 06:02:59

+0

哪些是IIS執行的模塊和***命令***?第一個EXECUTE_REQUEST_HANDLER模塊,第二個RELEASE_REQUEST_STATE,... – Kiquenet 2016-10-28 06:07:02