我正在尋找一種方法來查找SQL Server中的瓶頸,似乎超過32GB ram和8個核心上超過32個spindels是不夠的。是否有任何指標,最佳實踐或硬件比較(即每秒交易)?我們每天關閉需要幾小時,如果可能的話,我希望在幾分鐘或實時。我無法合併超過12k行/秒。目前,我不得不將流量分配給多臺服務器,但對於大約50GB的數據庫來說這是一個合適的解決方案嗎? 合併被包含在SP中並保持儘可能簡單 - 刪除重複輸入,插入新行,更新現有行。我發現我們放入單行合併的行越多,我們得到的每秒行數就越多。應用程序服務器運行在更多線程中,並使用其專用服務器上的所有內存和處理器。SQL硬件性能配給
1
A
回答
3
按照像Waits and Queues這樣的方法來確定瓶頸。這就是恰恰是是專爲什麼設計的。一旦確定了瓶頸,您還可以判斷是否存在硬件配置和校準問題(如果是這樣,那麼硬件是瓶頸),還是其他問題。
0
其基本思想是避免必須隨機訪問磁盤,無論是讀寫。如果不做任何分析,50 GB的數據庫至少需要50 GB的內存。然後,您必須確保索引與數據和事務日誌分開,並儘可能晚地寫入,並將關鍵表分割爲多個主軸。你在做這一切嗎?
相關問題
- 1. Sql server的硬件配置
- 2. 硬盤性能
- 3. Xamarin Mac硬件性能與舊的翻新硬件
- 4. 針對硬件的SQL查詢。可能?
- 5. 高性能OS /硬件/網絡優化
- 6. lucene/Solr性能和硬件要求
- 7. 未能分配給屬性'Windows.UI.Xaml.Controls.ContentControl.Content'
- 8. 屬性分配給在飛行功能
- 9. 未能分配給屬性'Microsoft.Phone.Controls.MenuItem.Click'
- 10. 未能分配給屬性'Windows.UI.Xaml.Controls.ContentPresenter.Content'
- 11. Sql通配符:性能開銷?
- 12. oprofile不能使用硬件性能計數器
- 13. SQL SELECT條件的性能
- 14. 是否可能在硬件
- 15. 可能檢測硬件?
- 16. 控制硬件功能
- 17. 包裝到硬件功能
- 18. 性能:更好地從硬盤解壓?
- 19. 硬盤讀取時的性能問題
- 20. 協議擴展:不能分配給只能得到的屬性
- 21. 不能分配給只讀屬性'原型'功能'類Template7
- 22. 配置性能
- 23. 不能分配值給文件變量
- 24. 創建腳本硬件配置文件?
- 25. SQL性能
- 26. 慢SQL性能
- 27. SQL EXCEPT性能
- 28. SQL性能MAX()
- 29. SQL EXISTS性能
- 30. SQL Server性能
避免隨機訪問是一個挑戰。沒有人知道下一批中哪些行會更新。實際情況是每秒大約30-40k合併(大部分更新),現在和未來幾個月足夠了。 – Pavel242 2011-01-16 18:42:55