ASP.NET 3.5：什麼會導致會話提前超時？

我們的會話設置爲120分鐘後超時。然而，最近，其中一臺生產服務器遇到了很多問題。由於我無法訪問服務器盒本身，因此我正在處理有限的信息。我們有兩臺服務器用於部署我們的網站。 Sever A在任何時候都能正常工作，但服務器B不斷有這些過期的會話問題。這是最近的一次，就像過去兩週一樣。ASP.NET 3.5：什麼會導致會話提前超時？

我知道我沒有提供足夠的信息來直接查明問題，但是有些問題可能會導致會話被重置而沒有韻或理由？

來源

2011-08-08 oscilatingcretin

您使用某種負載平衡嗎？ – canon

顯然，我修復了它。我並排打開了兩臺服務器的IIS7應用程序池高級設置，並注意到一個區別：Regular Time Interval設置在服務器A上爲5，在服務器B上爲1740.我將服務器A的設置更改爲1740（默認設置），問題立即停止。

奇怪的是，當服務器管理員回退到一個月前時，這開始發生了。不知何故，某些東西被擡高了，這些設置必須已經改變。

儘管我仍然不完全理解我做了什麼修正了事情，要麼是巧合，要麼是低5分鐘的設置是問題。

如果有人在意這點，那麼一定要這樣做。

來源

2011-08-10 23:42:01 oscilatingcretin

應用程序池可能由於多種原因之一而被回收。有許多的設置，並超過其中任何會導致ASP.NET回收：

回收工作進程（分鐘）
回收工作進程（在請求）
回收工作進程在以下時間
最大虛擬內存
最大使用的內存

如果您正在使用的進程內會話狀態，會話如果應用程序池回收，則會丟失。

如果沒有更改設置，很可能是由於內存泄漏（這可能不是真正的泄漏，但是應該釋放時保留的引用）導致的內存問題。

你說你在使用兩臺服務器。如果會話狀態丟失，這聽起來像你正在使用進程內會話狀態。在這種情況下，我認爲你正在使用'sticky sessions'進行負載平衡（後續的請求到達同一個服務器）？

如果我錯了，並且您正在使用共享狀態（例如SQL Server會話狀態提供程序或狀態服務器），是否可能是服務器上的時鐘不同步？

來源

2011-08-08 15:03:27

是的，兩個負載平衡的服務器。我從來沒有聽說過「進程內」會話，但它使用服務器內存作爲會話而不是數據庫表。我將不得不對1-3項進行更多的研究，但對於第4項和第5項，這些是基於硬件和/或操作系統配置還是基於web.config中的設置？換句話說，如果服務器有8GB內存，web.config中是否有最大虛擬/已用內存設置可以覆蓋該設置？ – oscilatingcretin

最近有什麼新的網站放在您的服務器上？我們在轉移到.net 4時遇到了這個問題，並沒有考慮爲新的.net 4站點創建一個新的應用程序池（作爲與.net 2/3.5相反的站點）。這導致應用程序池不斷重啓，因爲它們無法在同一應用程序池下運行。

你是否也上傳了任何可能讓自己停留在循環中的新代碼，這也可能導致應用程序池崩潰，導致會話重新啓動？

另一個想法..你有任何更新等待安裝在這臺服務器..這也造成了無法解釋的問題。

來源

2011-08-08 15:11:42 Bex

幾件事情浮現在腦海中：

正如@Steve摩根說，如果使用過程中會和「粘」會話，那麼它可以通過在負載均衡的問題引起的。當負載均衡時，會話應始終處於進程外，因爲坦率地說，「粘滯」並不意味着會話不會在兩臺機器之間反彈。這只是意味着它不太可能。如果負載平衡器超載，則用戶將被髮送到與第一個不同的服務器。

應用程序池回收是會話丟失的另一個原因;再次由於使用進程內會話管理。如果你搬出去處理它會隱藏的問題。這裏真正的問題雖然需要調查，因爲它幾乎總是由不好的代碼造成的。我的猜測是你有問題的組合。首先轉向進程外會話並設置狀態服務器。這將通過直接的痛苦。然後開始查看平衡器和Web服務器日誌，以查看是否需要更好的平衡器或需要更改代碼以堵塞內存泄漏。

來源

2011-08-08 15:26:19 NotMe

-1

工作液：

開始「ASP.NET狀態服務器」在您的服務（使之自動，所以它總是開始）
添加到您的web.config （副本如）：

<system.web> 
    <sessionState mode="StateServer" 
     stateConnectionString="tcpip=localhost:42424" 
     cookieless="false" 
     timeout="60" /> 
    <machineKey validationKey="DCB7132A24938F2166E362214ADAD861FA6B819E0A337F0E63257F87014A37B5EBC5D9F9AD107C38E3D3378BC35CBAF81407F3E4D8BA430FD65348DDCC469623" decryptionKey="DD09731F76271B2AAE6AE957626F8D1B8E3CBF11EF8E3CDDF01332CDF914D4B5" validation="SHA1" decryption="AES" /> 
</system.web>

**注：或生成你自己的機器鍵：http://aspnetresources.com/tools/machineKey

現在你可以回收您的應用程序池，修改你的web.config，或重新啓動您的Web服務 - 與會話到位！現在，您還可以啓用水池中的網絡花園以獲得更多性能。

來源

2011-12-01 05:09:45 oori

ASP.NET 3.5：什麼會導致會話提前超時？

回答

相關問題