通過記憶體和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裡的一些工具解決效能問題，這樣你就能從還未或已經行最小限度升級的現存的每項硬體效能。但是當你的確需要購買時，這些技巧有助於你作出正確的決策，做到物有所值。