通過記憶體和CPU進行SQL Server性能調優

 　　SQL Server記憶體還會影響性能，而如果在SQL Server系統中有太多的記憶體就是浪費錢，記憶體太少就又對性能十分有害。遺憾的是，決定你什麼時候在系統裡需要更多的記憶體很靈活。當記憶體出現問題時，你就會發現disk I/O就會增加，同樣磁盤列隊也會增加。你也會發現buffer cache hit ratio減少、page life會延長。随着記憶體需求的增加，你就會開始發現日志檔案裡的錯誤資訊。

　　SQL Server記憶體的一個重要部分已經分開了，這樣一來就造成了性能退化。持續時間：%n秒、工作組(KB)：%w、committed (KB):：%c、記憶體利用：%u。

　　SQL Server遇到了%o IO請求事件用15秒以上的時間在資料庫[%d] (%i)裡的[%f]檔案上完成。OS檔案處理為%h。偏移的最新IO 長度為: %l.。

　　但是這并不是這些錯誤被報告的唯一的一次，是以你需要和性能監控器metric一起使用來測定記憶體是否真的太低。

　　在處理SQL Server記憶體問題方面也有一些解決辦法，最簡單的就是解決辦法就是擴大伺服器記憶體增加可使用的buffer cache的數量。這樣做就增加了記憶體資料量、減少了你的disk I/O。其他的解決辦法包括遷移大空間表的叢集式索引以及隻使用這些表的非叢集式的索引，包括Primary Key。

　　在叢集式索引用于查找并且使用了叢集式的index seeks時就不同了。如果使用了另一個索引，它就不可能減輕任何記憶體壓力，因為叢集式的索引并沒有在記憶體裡。如果使用了叢集式的index scans，那麼在不遷移索引的情況下一個新的非叢集式的索引可能會有用。

　　如何監控CPU對列（CPU queuing）

　　CPU是硬體的另一個部分，它能夠導緻潛在的性能問題。大多數人隻看CPU的速度或數量。然而就如同磁盤一樣，CPU能夠成為瓶頸。如果出現了CPU瓶頸，你可能100%不會去檢視CPU的性能。CPU擁有指令對列的方式就如同I/O對列一樣。指令被下載下傳到CPU隊列中，并且執行之前的操作程式等待CPU變得可以使用。由于CPU的速度變得更快了，我們在CPU裡面做任何事情的速度也就加快了，但是我們一次也隻能做同樣多的事情。現在我們可以使用雙核、三核、四核以及多核的CPU。這樣我們一次能夠執行更多的指令。

　　你可以利用SQL Server性能監控器監控你的CPU。你會在System目标下面發現PerfMon，它有一個電腦的名字“處理機隊列長度”。幾乎任何其他大于零的隊列長度都表明你需要增加一些操作程式，這些操作程式是SQL Server都能同時執行的。但是這并不表明需要一個更快的CPU，而是需要一個更多核的CPU。今天最新的伺服器每台伺服器都支援32核，一些進階的伺服器支援64核（當chase按比例範圍共同支援64核時）也可以建立（僅僅是某些廠商）。

　　在第一部分和第二部分裡，我已經指出了硬體裡的一些地方。這些技巧不是解決性能問題最全面的、最終的解決方案。表的設計和索引的調整經常是并且長期是非常重要的。今天的SQL Server有望在更長的時間内做更多的事情，這樣才能使硬體調整對資料庫平台更加重要。用arsenal裡的一些工具解決性能問題，這樣你就能從還未或已經行最小限度更新的現存的每項硬體性能。但是當你的确需要購買時，這些技巧有助于你作出正确的決策，做到物有所值。

    本文轉自 Fanr_Zh 部落格園部落格，原文連結：http://www.cnblogs.com/Amaranthus/archive/2011/03/27/1997087.html，如需轉載請自行聯系原作者