Reading theory is important but doing practical in real life helps remembering a concept for longer time. In last post about resource governor, we have learned the basics. In this blog, we would see resource governor in action. If you have SQL Server 2014 installed then you can easily follow the steps and copy/paste the scripts. As a demo, we would create two resource groups and pools which different settings.

Step 1: Create Resource Pools

As a first step, we would create resource pool for limiting IO done by a specific pool. ThousandIOPs sets the maximum I/Os per second (IOPS) to 1000 and TenIOPs sets maximum IOPS to 10. This is done via parameter MAX_IOPS_PER_VOLUME.

CREATE RESOURCE POOL [ThousandIOPs] WITH
(
    MAX_IOPS_PER_VOLUME = 1000
)
GO
CREATE RESOURCE POOL [TenIOPs] WITH
(
    MAX_IOPS_PER_VOLUME = 10
)
GO

Step 2: Create Workload Groups tied to resource pool

In below code I created Resource Groups named “FastIO” and “SlowIO” and associated them with my Resource Pool named “ThousandIOPs” and “TenIOPs” respectively.

-- Create a  Workload Group for FastIO 
CREATE WORKLOAD GROUP [FastIO]
USING [ThousandIOPs]
GO
-- Create a new Workload Group for throttled IO
CREATE WORKLOAD GROUP [SlowIO]
USING [TenIOPs]
GO

Step 3: Define a classifier function to bind request to workgroup

In Step 3, I need to define a classifier function that will identify the resource group to which request should be categorized. You can notice that I have used SUSER_NAME() function to get resource group name as output parameter. In other words, if use SlowIO logs in, he would be bound to group SlowIO and hence tied to TenIOPs.

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

Step 4: Register classifier_function to resource governor

So far we have setup Resource Governor to control I/O. We need to do one last thing.  We need to alter Resource Governor to use classifier function, defined in step3, and then reconfigure it to use all my new settings.  This can be done by running the following code:

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

Testing IO Resource Governor

To test resource governor, we will create two logins SlowIO and FastIO and they would be falling into different pools TenIOPs and ThousandIOPs respectively. I have given sysadmin rights for simplicity of demo.

Create login SlowIO with password = 'pass@word1'
GO
Create login FastIO with password = 'pass@word1'
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [SlowIO]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [FastIO]
GO

Create database, table and populate data using below script.

CREATE DATABASE rgiotest 
go 
USE rgiotest; 
go 
CREATE TABLE iotest 
  ( 
     id             INT IDENTITY  CONSTRAINT [PK_IOTest_ID] PRIMARY KEY CLUSTERED (id ASC), 
     iintegercolumn INT, 
     ccharcolumn    CHAR(50) 
  ); 
go 
SET nocount ON; 
INSERT INTO iotest 
            (iintegercolumn, 
             ccharcolumn) 
SELECT TOP (20000) Row_number() 
                     OVER( 
                       ORDER BY a.object_id), 
                   'X'
FROM   sys.all_columns AS a 
       CROSS JOIN sys.all_columns AS b
go 100 -- this would run above insert 100 times

Above script took around 30 seconds on my laptop. Now, I would run the script to do a lots of read using two different logins.

CHECKPOINT
DBCC DROPCLEANBUFFERS

USE RGIOTEST;
GO
IF OBJECT_ID ('tempdb..#IOTest') is not null
   DROP TABLE #IOTest;
GO
SELECT top 2000000 * INTO #IOTest FROM IOTest;
GO

I have used DROPCLEANBUFFERS in above script because I don’t want SQL to read data from memory but do a physical IO.

Logged in using SlowIO account

Script has taken 37 seconds and below is the perfmon counters which I have spoken in last blog.

The value is throttled to around 10 which is what we have capped (MAX_IOPS_PER_VOLUME = 10)

Logged into using FastIO account

Here the same query executed in 4 seconds.

The value is much under control. We have capped to 1000 and we are much under limits.

I must say that the demo shown here is extremely simple, but you can must have got an understanding about you how to setup and use the Resource Governor to throttle IO in SQL Server 2014.

Hope you are learning something new about SQL Server 2014 from this series.

Have you ever come across a situation where you want to re-index complete database and other queries are facing slowness because of IO bottleneck? In earlier version of SQL Server, resource governor was available for CPU and memory. In SQL Server 2014, resource governor for IO was also introduced. This would enable DBA to manage and control the allocation of resources. To read more about earlier version, you can refer books online. As per documentation, below are the goals which were thought while designing RG:

• Minimize impact run-away queries:- Run-away queries are the queries which would consume resources for long time. Think of a reporting query which consumes 100% as soon as it runs. If such query is executed, other queries would suffer from resource bottleneck.
• Improve predictability of query executions:- During maintenance tasks (rebuild index, update stats) or ETL, there might be a heavy use of resource by those processes. This would cause unpredictable time of query executions. This is generally not a desirable situation.

Let’s first understand the basic functionality and various terms used in resource governor. Below picture shows various components of resource governor.

As soon as request comes from any source it is assigned to a particular resource group via user defined function known as “classifier function”. Classifier function can use various connection attributes and provide the bucket in which request should fall into. These buckets are called Resource Group. Those request which are not classified, would go to default group (orange color). Default group would use remaining resources. We should also remember that there is a internal pool (green color) which can’t be controlled via resource governor. The maximum number of pools which can be configured in SQL Server is 64.

Someone may still ask, why I/O needs to be governed? Think of a situation when you are database services provider. There are many customers who are hosting database on your server. What if one of your naughty customer runs read/write heavy workload? Someone else would be impacted. Right?

Let’s see what’s new in resource governor. Highlighted is the additional which is available in SQL 2014. This means that now we have ability to set/get/alter minimum and maximum I/O operations per second (IOPS) per volume to resource pool.

CREATE RESOURCE POOL pool_name
[ WITH
    (
        [ MIN_CPU_PERCENT = value ]
        [ [ , ] MAX_CPU_PERCENT = value ] 
        [ [ , ] CAP_CPU_PERCENT = value ] 
        [ [ , ] AFFINITY {SCHEDULER =
                  AUTO | ( <scheduler_range_spec> ) 
                | NUMANODE = ( <NUMA_node_range_spec> )} ] 
        [ [ , ] MIN_MEMORY_PERCENT = value ]
        [ [ , ] MAX_MEMORY_PERCENT = value ]
        [ [ , ] MIN_IOPS_PER_VOLUME = value ]
        [ [ , ] MAX_IOPS_PER_VOLUME = value ]
    ) 
]
[;]

There are various changes introduced in DMVs to monitor resource governor for IO and new DMVs are also added.

Below are existing DMVs having new columns about

• sys.resource_governor_configuration
  • max_outstanding_io_per_volume
• sys.dm_resource_governor_resource_pools:
  • min_iops_per_volume
  • max_iops_per_volume
  • read_io_queued_total
  • read_io_issued_total
  • read_io_completed_total
  • read_io_throttled_total
  • read_bytes_total
  • read_io_stall_total_ms
  • read_io_stall_queued_ms
  • write_io_queued_total
  • write_io_issued_total
  • write_io_completed_total
  • write_io_throttled_total
  • write_bytes_total
  • write_io_stall_total_ms
  • write_io_stall_queued_ms
  • io_issue_violations_total
  • io_issue_delay_total_ms

New DMV:

• sys.dm_resource_governor_resource_pool_volumes
  • pool_id
  • volume_name
  • read_io_queued_total
  • read_io_issued_total
  • read_io_completed_total
  • read_io_throttled_total
  • read_bytes_total
  • read_io_stall_total_ms
  • read_io_stall_queued_ms
  • write_io_queued_total
  • write_io_issued_total
  • write_io_completed_total
  • write_io_throttled_total
  • write_bytes_total
  • write_io_stall_total_ms
  • write_io_stall_queued_ms
  • io_issue_violations_total
  • io_issue_delay_total_ms

Other than DMVs there are XEvents and Performance counters added to monitor and troubleshoot resource governor related to IO. Since my instance name is SQL2014, the counter name is MSSQL$SQL2014:Resource Pool Stats. I have highlighted 8 new counters (4 for read and 4 for write) which are newly added in SQL 2014. Note that these counters are “per pool” basis. Here is the query to get list of counters.

Select distinct object_name, 
counter_name from sys.dm_os_performance_counters 
where object_name like '%Pool%'

@blakhani