2010-07-02 36 views

回答

0

您是否使用默認的SqlMembership提供程序?還是你自己製作一些東西?如果它是選項2,我建議你開始分析你的代碼並對它進行壓力測試。您還可以使用SQL Profiler查看發送到數據庫的內容。您也可以使用sp_lock或更新的sys.dm_tran_lock來查看是否存在行鎖定。

是否有一些其他進程在同一臺服務器上運行,可能導致SQL Server無法獲得足夠的內存來正常工作? Sysinternals有一些很棒的工具來檢查這些。

+0

是的,我們正在使用默認的SqlMembership提供程序,還有SQL Profiler來查看發送到數據庫的內容以及它的外觀。同樣在探索問題上,我們注意到sql server中的內存在使用中不是釋放,因此應用程序速度變慢。但我們不知道爲什麼會發生這種情況,以及如何克服這種情況。 – Shrik 2010-07-02 07:38:03

0

這個問題很模糊。您是在談論使用基於SQL Server的提供程序的應用程序登錄,還是登錄到實際的數據庫服務器本身(通過Management Studio或類似的東西)?

+0

不完全是,實際上我們無法檢測到數據庫連接或軟盤問題。 \t \t爲了與sql server正常連接我們爲每個用戶實現連接池從連接池中單獨建立連接並在註銷時關閉仍然會遇到問題 – Shrik 2010-07-02 13:08:07

1

@Shrik:SQL Server是A類內存用戶 - 按設計。默認情況下,它設置爲獲取所有可以抓取的內存。它實際上將數據從磁盤移動到物理內存中 - 以便將來訪問這些數據的速度會更快。

當sql服務器服務位於它自己的盒子上時 - 這並不是什麼問題。但是當其他應用程序試圖在該框上運行時,會出現嚴重的資源瓶頸。這個場景就是我在你討論的兩行之間閱讀的內容。

如果您的應用程序正在SQL框上運行,並且每當sql服務器開始「做它的事情」時性能都會受到影響,請執行以下操作之一:限制內存sql的可用數量(不太好) sql server自己的盒子。

如果你的sql服務器已經在它自己的盒子上,我將要做的第一個區分「緩慢」起源的地方是運行典型的「緩慢」查詢/語句 - 兩者都來自SQL的應用程序&服務器,通過SSMS。我知道,所以非常不高科技,但非常有說服力。如果查詢通過SSMS快速且靈活,那麼就單獨保留DBMS,並專注於應用程序和網絡物理/軟層。如果查詢不太好 - 請查看@SQL Server。

如果是sql server,我的問題是你的查詢表現不佳,你描述它的方式會隨着應用程序的進展而變得更糟,但在應用程序重新啓動後效果會更好嗎? (順便說一句,如果應用程序重新啓動,但不是Sql Server「修復」問題,則可能是應用程序問題)。

和往常一樣,日誌是你的朋友!看看SQL Server在說什麼。例如,您的應用可能會大量使用SQL CLR。第一次調用程序集時,它是SLOOOOW。第二次,FAST。 SQL Server管理其內存空間,有時它會將組件從內存中移出。下一次組裝被稱爲 - 猜測用戶的體驗是什麼? SLOOOOOW。猜猜在哪裏可以看到SQL Server從內存中推送程序集?

讓我們試着解決一些問題,然後發佈結果,我敢打賭有人可以幫助您解決更多問題。記住 - 任何日誌,錯誤消息或硬數據都可以幫助我們回答您的問題。

祝你好運!

相關問題