程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> 如何在SQL Server 2014中用資源調控器壓制你的存儲?

如何在SQL Server 2014中用資源調控器壓制你的存儲?

編輯:關於SqlServer

在今天的文章裡,我想談下SQL Server 2014裡非常酷的提升:現在你終於可以根據需要的IOPS來壓制查詢!資源調控器(Resource Governor)自SQL Server 2008起引入,但提供的功能還是有所限制:你只能限制CPU時間(這個已經很棒了),還有你能限制查詢(從每個獨立的查詢)內存量。

但作為DBA的你,你經常會進行一些數據庫維護操作,例如索引重建,DBCC CHECKDB操作等。我們都知道,這些操作會在你的存儲裡帶來大量的IOPS直至峰值。如果在7 * 24在線的數據庫來說,這個會影響你的生產力,給業務和銷售額帶來很大影響。

自SQL Server 2014開始,這個情況就變了,因為你可以通過資源調控器來部署指定的資源池來限制IOPS使用率。當你隔離你的DBA操作到指定的資源池時,你能指定資源池可以使用的最大IOPS(包括最小IOPS)。因此你可以壓制下DBA操作需要的IOPS。你的生產工作量就可以更好的使用你的存儲。更多信息可以查看微軟在線幫助。

我想用一個非常簡單的例子來展示下這個行為。假設你是DBA,正要進行常規索引重建操作,這個需要通過資源調控器對它們的最大IOPS使用率進行控制。第1步我們為DBA操作創建專用的資源池和工作負荷組。

-- Create a new Resource Pool for the DBAs.
-- We use a very high value for MAX_IOPS_PER_VOLUME so that we are
-- currently running unlimited.
CREATE RESOURCE POOL DbaPool WITH
(
 MAX_IOPS_PER_VOLUME = 100000
 )
GO

-- Create a new Workload Group for the DBAs
CREATE WORKLOAD GROUP DbaGroup
USING DbaPool
GO

從剛才的代碼可以看到,CREATE RESOURCE POOL語句現在為你提供MAX_IOPS_PER_VOLUME屬性(包括MIN_IOPS_PER_VOLUME)。這裡我設置了一個很高的值,因此在第一次執行時IOPS不會受限,這裡我們根據需要的IOPS建立了初始基線。下一步我會創建資源調控器需要的分類函數。

-- Create a new Classifier Function for Resource Governor
CREATE FUNCTION dbo.MyClassifierFunction()
RETURNS SYSNAME WITH SCHEMABINDING
AS
BEGIN
DECLARE @GroupName SYSNAME
 
IF SUSER_NAME() = 'DbaUser'
BEGIN
SET @GroupName = 'DbaGroup'
END
ELSE
BEGIN
SET @GroupName = 'Default'
END
 
RETURN @GroupName;
END
GO

在分類函數裡我們根據登錄進行評估。如果登錄是DbaUser,進入的會話會在DbaGroup工作負荷組裡。否則就進入默認的工作負荷組。最後我們在資源調控器注冊並配置它,這樣我們的設置就生效了。

-- Register the Classifier Function within Resource Governor
ALTER RESOURCE GOVERNOR WITH
(
 CLASSIFIER_FUNCTION = dbo.MyClassifierFunction
 )
GO

-- Reconfigure Resource Governor
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

現在當你創建名為DbaUser的登錄時,你可以用它連接到你的SQL Server。你可以在DMV sys.dm_exec_sessions 看下 group_id列驗證下到來的會話是否在正確的工作負荷組裡。下一步我在ContoRetailDW數據庫的FactOnlineSales表裡的DataKey裡創建一個非聚集索引。

-- Create a simple Non-Clustered Index
CREATE NONCLUSTERED INDEX idx_DateKey ON FactOnlineSales(DateKey)
GO

我們從開始就創建了資源池,現在在我們在我們的資源池裡並沒有限制。因此當我們現在進行剛才創建的非聚集索引的索引重建時,SQL Server會占用大量的IOPS。我們可以通過性能監控裡的“SQL Server:Resource Pool Stats:Disk Write IO/Sec”性能計數器來驗證剛才創建的資源池。

ALTER INDEX idx_DateKey ON FactOnlineSales REBUILD
GO

可以看到索引重建花費近100的IOPS。接下來我要做的是限制DbaPool資源池為僅50的IOPS:

-- Let's change the Resource Pool by lowering the maximum IOPS.
ALTER RESOURCE POOL DbaPool WITH
(
 MAX_IOPS_PER_VOLUME = 50
 )
GO

現在當你執行索引重建時,在性能監視器裡可以清楚看到,在特定的資源池裡只有平均50 IOPS。

另外Disk Write IO Throttled/sec性能計數器也會告訴為你資源調控器的IOPS的限制數。

使用以前的資源調控器,查詢本身毫無辦法,它是否被壓制了。這對性能調優也是個非常重要的因素。當啟用資源調控器時,沒有特定的等待類型出現在SQL Server裡。我的測試顯示一旦資源調控器啟用時,有更多的PAGEIOLATCH_SH/PAGEIOLATCH_EX等待類型,這就對了。下面2個圖片顯示了對於發生索引重建的會話裡具體的等待類型信息——第1個沒有資源調控器,第2個有資源調控器壓制了IOPS。

從2個圖中可以看到,2個運行的測試有巨大的區別,尤其是在PAGEIOLATCH_EX SOS_SCHEDULER_YIELD等待類型。

從我站在IOPS壓制來看,對於已有的功能來說,資源調控器是個很好的附加,這讓資源調控器更加成熟。

大家可以嘗試用這個新功能解決IOPS方面的問題。

以上所述就是本文的全部內容,希望對大家的學習有所幫助。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved