[zhuan]SQLSERVER 數據庫性能的基本

SQLSERVER 數據庫性能的基本

好久沒有寫文章了，在系統正式上線以前，DBA通常都要測試一下服務器的性能

好比你有不少的服務器，有些作web服務器，有些作緩存服務器，有些作文件服務器，有些作數據庫服務器

作數據庫服務器的那臺服務器性能要相對較好，磁盤，內存，CPU等等，

那麼在選用其中某一臺服務器做爲數據庫服務器以前須要測試每一臺服務器的性能

而且須要設置一些硬件的參數，例如設置磁盤控制器的參數，參考文章：Writeback和Writethrough區別

那麼具體怎麼測試呢？怎麼得出測試指標呢？

你們能夠參考這篇文章：SQL Server Database Engine Performance Tuning Basics

---

正文

隨着市場份額的SQL Server的發展隨着時間的推移,有愈來愈多的對SQL服務器性能調優的需求。

有不一樣的團隊和我的採用各類各樣的方法提升SQLSERVER服務器的性能,

並且我認爲這些記錄SQLSERVER troubleshooting 的基本步驟和提升各類程序性能的文檔對SQLSERVER社區是有意義的

 

磁盤

爲了SQLSERVER能有效運行，監控和優化SQLSERVER的磁盤子系統是一個重要的方面

咱們須要很是明確磁盤的性能需求

Avg. Disk Sec/Read 這個計數器是指每秒從磁盤讀取數據的平均值

下面的列表顯示這個計數器值的範圍，並指出這個計數器所處範圍的意思

少於 10 ms - 很是好
在 10 - 20 ms 之間- 還能夠
在 20 - 50 ms 之間- 慢，須要關注
大於 50 ms –嚴重的 I/O 瓶頸

 

磁盤性能測試工具

（1）CrystalDiskMark

（2）HDTUNE 硬盤檢測修復工具 

（3）ATTO Disk Benchmark 

 

 

 

辨別I/O瓶頸

PhysicalDisk Object：Avg. Disk Queue：所選物理磁盤在取樣期間被排隊的磁盤讀寫請求平均值

若是你的磁盤隊列長度常常超出SQLSERVER磁盤使用峯值的2倍，那意味着可能有I/O瓶頸了

 

Avg. Disk Sec/Read：每秒從磁盤讀取數據的平均值 

Avg. Disk Sec/Write：寫入數據到磁盤的平均時間，Avg. Disk Sec/Read參考指標

Physical Disk:%Disk Time磁盤時間是所選磁盤驅動器繁忙處理讀寫請求時所花時間的百分比，一個指標就是若是這個值大於50%，那麼就存在I/O瓶頸

Avg. Disk Reads/Sec：在磁盤上的讀操做的比率。確保這個數字小於磁盤吞吐量的85%。當這個值超過85%磁盤訪問時間會以指數式增加

Avg. Disk Writes/Sec c：在磁盤上的寫操做的比率。確保這個數字小於磁盤吞吐量的85%。當這個值超過85%磁盤訪問時間會以指數式增加

 

對於更多的信息，能夠參考「如何建立性能計數器集」：http://technet.microsoft.com/en-us/library/cc722148.aspx

 

磁盤驅動器的位置：

爲了避免同的目的，你須要使用不一樣的驅動器來存放下面的東西
獨立的磁盤延時需求：
數據庫大於15ms

事務日誌大於2ms

Tempdb數據庫大於2ms

 

磁盤速度的優先級

意思是說，Tempdb放在單獨的物理磁盤，事務日誌文件放在單獨的物理磁盤，數據文件放在單獨的物理磁盤，操做系統放在單獨的物理磁盤，

數據庫備份文件放在單獨的物理磁盤

 

通常咱們的作法：不可能有那麼多單獨的物理磁盤，通常就是作了磁盤陣列的存儲

C盤放操做系統文件

D盤放數據文件和事務日誌文件 和Tempdb數據文件和Tempdb日誌文件

E盤放數據庫備份文件

 

當格式化磁盤的時候，對於要存放SQLSERVER數據文件和日誌文件的磁盤，儘可能不要使用默認的磁盤分配單元

 

使用64k 簇大小 Allocation Unit 來格式化磁盤，至於爲什麼你們能夠看一下這篇文章：如何用Procmon.exe來監視SQLSERVER的logwrite大小

 

---

殺毒軟件

殺毒軟件會對SQLSERVER的一些功能產生問題，使用殺毒軟件的排除功能將數據庫的文件排除在掃描的範圍外是很重要的（放入殺軟的掃描例外裏）

下面的文件類型是須要排除在外的

*.mdf, *.ndf, *.ldf, *.bak

相關文章：殺毒軟件致使YourSQLDba備份失敗

文章中說到由於殺毒軟件掃描備份文件夾並鎖住了備份文件夾，致使SQLSERVER備份數據庫失敗

 

---

內存

老是給分配最大的內存給SQLSERVER實例在服務器屬性那裏設置

注意:最大內存設置只對SQLSERVER的buffer cache部分有效，不包括SQLSERVER的一些須要內存的功能，例如複製

（SQLSERVER2012的最大內存設置已經能夠限制buffer cache部分和非buffer cache部分的內存）

 

爲了指明Non-Buffer Pool 的內存佔用，使用下面的說明

SQL Server’s buffer pool外的內存需求（這個需求不是說你設置了SQLSERVER最大內存以後，所剩下的內存的需求，無論你有沒有設置SQLSERVER的最大內存

下面幾項都是服務器固定須要消耗的內存，而不管你的服務器內存是4G,8G仍是16G，下面幾項都會固定佔用服務器的內存）

（1）操做系統須要佔用2GB內存，若是是64位操做系統，操做系統佔用內存不大於3GB

（2）SQLSERVER工做線程的倍數，你能夠在SQLSERVER服務器屬性裏設置最大工做線程，

每一個線程會使用0.5MB內存（X86服務器）

每一個線程會使用2MB內存（X64服務器）

每一個線程會使用4MB內存（Itanium服務器）

注意：0.5MB內存存放的是線程自身的數據結構和相關信息，不包括數據

爲何各類服務器所分配的線程內存不同，這個是操做系統分配的，SQLSERVER並無作特別的設置！

若是你設置最大的工做線程數爲10個，服務器是X86，恰好服務器用盡了10個線程，那麼佔用的內存是10*0.5MB=5MB內存

（3）1GB的 multi-page 內存佔用，連接服務器和其餘SQLSERVER外圍的程序佔用

（4）運行在服務器上的程序可能佔用1~3GB內存，例如備份程序

例子

 例如，一個8核服務器，16GB內存，運行着SQLSERVER2012 X64，上面運行着第三方的備份程序，你能夠參照下面的清單

 （1）3GB 給 Windows (2GB for 32 Bit Windows)

 （2）1GB 給 SQLSERVER 工做線程 (576 × 2MB 大概)

 

各類CPU和SQLSERVER版本組合自動配置的最大工做線程數
CPU數       32位計算機      64位計算機
<=4             256               512
8                 288               576
16               352                704
32               480                960

（3）1GB for MPAs, etc. （multi-page apply）

（4）1~2 GB 給 備份程序.

 

您可以找到更多信息關於「最大工做線程選項」http://technet.microsoft.com/en-us/library/ms187024(v=sql.105).aspx

(For SQL Server 2008).

 

開啓Lock Pages in Memory 選項

Windows組策略決定哪一個Windows帳戶能使進程將他的數據逗留在物理內存裏，防止操做系統把程序數據從物理內存換頁換出磁盤上的虛擬內存

這可以給您帶來性能上的提高，特別遇到內存壓力的時候

---

TempDB 數據庫的優化

默認，Tempdb數據庫只有一個數據文件和事務日誌文件。然而，爲了性能的優化，跟着下面給出的建議最佳實踐

 

TempDB數據庫的存儲計劃

（1）設置Tempdb數據庫的恢復模式爲簡單（默認就是簡單的），簡單模式可以自動回收日誌空間使日誌空間的需求保持最小

（2）不要讓Tempdb的數據文件自動增加，這能夠減小管理動態文件增加的CPU開銷

 對於Tempdb數據庫，能夠分開多個數據文件（總的Tempdb數據庫數據文件的數量=CPU邏輯處理器的數量，好比8核服務器能夠分8個數據文件）

每一個數據文件的大小要同樣

（3）嘗試將這些數據文件存放在不一樣的磁盤驅動器上以利用並行I/O

（4）TempDB 數據文件和 日誌文件應該存放在較快速度的磁盤上（若是可能推薦放在作了RAID 1的磁盤上）

（5）使用RAID-10 或者 SSD 磁盤

（6）預先定義好Tempdb數據庫的文件大小

（7）設置Tempdb總的大小爲當前數據庫實例中最大的那個數據庫的25% 

（8）設置Tempdb數據文件自動增加的固定大小小於200MB

（9）你應該設置Tempdb數據庫的數據文件數量跟邏輯CPU的數量一致，最多不超過8個數據文件

---

CPU的優化

設置最大並行度（Max Degree of Parallelism）

定義多少個邏輯CPU能並行執行查詢

 

不少微軟的產品，例如SharePoint 和 Dynamics CRM都把這個設置設置爲1，這個是推薦的設置

對於 SharePoint  的LOB 應用程序，當你看到有不少CXPACKETS 的等待類型在你的SQLSERVER服務器裏，

你應該考慮一下將這個設置（Max Degree of Parallelism）設置爲1

 

---

索引填充因子

若是你的SQLSERVER服務器有很是高的事務量TPS （transaction per second）

你的索引有比較高碎片級別，考慮一下將填充因子設置爲「80%」

而且使用下面的SQL語句檢測一下索引碎片

SELECT  DB_NAME(ps.database_id) AS 'Database Name' ,
        OBJECT_NAME(ps.OBJECT_ID) AS 'Database Object' ,
        ps.index_id ,
        b.name ,
        ps.avg_fragmentation_in_percent
FROM    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS ps
        INNER JOIN sys.indexes AS b ON ps.OBJECT_ID = b.OBJECT_ID
                                       AND ps.index_id = b.index_id
WHERE   ps.database_id = DB_ID('ReportServerTempDB')
ORDER BY ps.avg_fragmentation_in_percent DESC
GO

 

---

使用Performance Monitor (Perfmon.exe)來監控系統性能

爲了捕獲SQLSERVER特定的性能指標，你須要使用下面的計數器

Processor: % Processor Time  ：平均應該低於75% （最好低於50%）   

System: Processor Queue Length：平均每一個邏輯CPU應該低於2，例如在一個2邏輯CPU的機器上，他應該保持在4

Memory—Pages/sec：平均應該低於20（最好低於15%）

Memory—Available Bytes ：可用內存應該保持在50MB以上

Physical Disk—% Disk Time：
Physical Disk—Avg. Disk Queue Length ：每一個磁盤平均應該低於2，例如：一個RAID5磁盤，這個指標應該平均低於10

Physical Disk—Avg. Disk Reads/sec ：取決於CPU和磁盤的大小，應該低於相對應磁盤的吞吐量的85%

Network Interface—Bytes Total/sec ：用於統計網絡帶寬方

SQL Server: Buffer Manager—Page Life Expectancy：用於統計內存，應該保持在300秒
SQL Server: 通常統計用戶的鏈接數 來估計大概使用的內存
SQL Server: Databases— Transactions/sec ：每秒的事務數
SQL Server: Databases—Data File(s) Size KB：用於統計數據庫數據文件的大小，衡量磁盤子系統的性能
SQL Server: Databases—Percent Log ：衡量磁盤子系統的性能