I have already explained top performance counters to detect Memory and Disk IO bottlenecks in SQL Server in my last articles. Have a look at them (attached below) to get Memory and Disk IO related performance counters and their ideal values for healthy system.

• Top 10 Performance Counters to Identify SQL Server Memory Pressure
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

Generally, CPU bottleneck arises because of either your system has not enough CPUs to process current workload or your transactions or applications are poorly designed that causes the high CPU. To deal with SQL Server CPU pressure, we need to either find the high CPU intensive queries and optimize them or increase the total CPU counts of the database server to handle current workload. There can be multiple reasons for high CPU usage like high recompilations of SQL Queries, OS issues, Query design issues: Sorting Joins, Poor Indexes, Condition Clauses etc. Here, I am going to explain about top perfmon counters to identify SQL Server CPU bottleneck.

Perfmon Counters for CPU Usage

Here, I am going to describe about perfmon counters for CPU usage in SQL Server. Ideally, first we should start with looking at CPU usage in Windows Task Manager. If the CPU utilization is continuously going beyond 85%, it means your system is facing CPU bottleneck. Find the list of performance counters to identify SQL Server CPU bottleneck.

Processor: % Processor Time 

One of the very useful CPU perfmon counter for SQL Server is Processor: % Processor Time. This counter displays the percentage of time CPU spends executing a thread that is not idle. If your system is frequently reaching beyond 85% then it means your system is facing CPU bottleneck. The acceptable value for this counter should be less than 50%.

Processor: % User Time

Windows operating system has two modes of processing for any process. One is Kernel mode another one is user mode. This counter shows the percentage of time a process spends executing user processes like SQL Server. If this counter is high it means CPU pressure is because of SQL Server or because of user applications. You should focus to retrieve CPU intensive queries to get the culprit transactions that are causing high CPU pressure. There is no idle value for this counter. You should benchmark each system based on your workload.

Processor: % Privilege Time

This counter shows the percentage of time the processor spends on execution of Microsoft Windows kernel commands, such as processing of SQL Server I/O requests. This counter captures the information about kernel mode and indicates towards poor performance of disk subsystems. Monitor DISK IO related performance counters to identify DISK IO bottleneck and if possible, consider installing a faster or more efficient disk subsystem.

Processor: % Interrupt Time

This counter Processor: % Interrupt Time tells about the time a processor spends receiving and servicing hardware interruptions during specific sample intervals. This counter indicates a possible hardware issue if the value is greater than 15 percent.

System: Processor Queue Length

This is an important perfmon counter to detect CPU bottleneck. This counter gives information about the number of threads waiting for processor time. If value of this counter is greater than zero then this is a sign of CPU bottleneck. We can further check Compilations/sec and Re-Compilations/sec. A high number of compilations and recompilations usually indicates poor reuse of the query plans. This can be fixed by optimizing your queries and stored procedures.

System: Calls/sec

Any system would have either software calls or application related calls or hardware related calls. This counter System: Calls/sec metric shows the number of software calls to the operating system service routines per second. Similarly, another CPU perform counter Processor: Interrupts/Sec shows the number of hardware calls to the processor. Both perfmon counters can be used to determine the source of the performance issues. The acceptable values for System: Calls/sec are under 20,000. Higher values might indicate excessive operating system activity caused by software applications.

Context Switches/sec

Context Switches occurs when kernel switches processor from one thread to another. The acceptable Context Switches/sec value should be less than 2,000 per processor. If you are observing constant high values of Context Switches/sec and Processor: % Processor Time on your system then this would be a clear sign of processor bottlenecks. Permanent solution to reduce CPU bottleneck is to change the processor to a more powerful one, or add an additional to existing ones.

You might have seen high Context Switches/sec values for systems that are running with multiple SQL Server instances or a system that is hosted other applications along with SQL Server.

Here I have described top perfmon counters for CPU usage on your database server. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Disk and Performance Impact of running Online Index Rebuild Operation
• Understanding Database Shrink Operation and Why should you Avoid it?
• Fix Error 701: There is Insufficient System Memory to Run this Query
• How to Improve Bulk Data Load Performance?

The post Top Perfmon Counters to Identify SQL Server CPU Bottleneck appeared first on Techyaz.com.

• Fix SQL Server Error 701: There is Insufficient System Memory to Run this Query

We can use Windows PerfMon utility to gather current values of all given performance counters. Just type perfmon in run prompt to launch perfmon tool to gather memory related performance counters. Although, Microsoft has also given a DMV related to performance counters that is very useful in collecting data and detecting CPU, IO or memory bottleneck in SQL Server. You can run below command to get all performance counters and their respective values using DMV sys.dm_os_performance_counters. You can also use this DMV to get performance counter values to identify memory pressure in SQL Server.

Select * from sys.dm_os_performance_counters

By default, SQL Server changes its memory requirements dynamically, on the basis of available system resources. I have explained SQL Server Memory Management and how SQL Server allocated memory to their transactions in below attached article.

• SQL Server Memory Allocation & Role of MIN/MAX Server Memory Configuration

Performance Counters to Identify SQL Server Memory Pressure

Let’s discuss top perfmon counters for memory usages to identify its bottleneck. Below is the list of top 10 performance counters to identify SQL Server Memory pressure. If you want to read CPU and Disk IO related perfmon counters then i would suggest you to read below attached articles.

• Top Perfmon Counters to Identify SQL Server CPU Bottleneck
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

Memory: Available Bytes

First thing you should look at in case of memory bottleneck in SQL Server is the available memory that can be used by processes. You can get this value by looking at the counter Available Bytes under object Memory. Low value of this counter shows the memory shortage on this server.  Now, you should focus behind the reason of this memory shortage. There might be possibility that some of your applications running on your server are not releasing memory or your system has not enough memory to perform current workload that leads to the memory bottleneck in SQL Server.

Memory: Pages/sec

This counter indicates the total number of pages that are either read from disk or written to the disk due to page fault. When a process requests a data page that is not in memory then it will be retrieved from disk to memory. This process is known is page fault. High value of this counter could indicate the excessive paging. We should further monitor Memory: Page Faults/sec counter to go indepth information. The average Pages/sec value should be below 50. A high value of Pages/sec indicates intensive memory activities like read from and write to disk. It means transactions are getting enough memory that is why they are using disk to process their requests.

Memory: Page Faults/sec

High value of counter Memory: Pages/sec could indicate the excessive paging. Next, we should monitor the Memory: Page Faults/sec counter to make sure that the disk activity is not caused by paging. If you want to determine whether SQL Server or another process is causing excessive paging then we should monitor the Process: Page Faults/sec counter for the SQL Server process instance. This will give an exact picture whether SQL Server is causing this paging issue or not.

Process: Working Set

This counter shows the amount of memory a process can use. This counter value shows whether you have set optimum value in min server memory and max server memory configuration or not. If this value shows constantly below min server memory and max server memory then you have configured too much memory for your SQL Server.

SQL Server: Buffer Manager: Buffer Cache Hit Ratio

This is very important counter and this counter shows the number of percentage that has been satisfied using data cache. Suppose the value of buffer cache hit ratio for your server is 94 it means 94% of total requests for data have been processed using data cache.

The ideal value for this counter is more than 90. Higher the value better the memory health.

SQL Server: Buffer Manager: Page Life Expectancy

Page Life Expectancy is very important counter to measure memory pressure for your system. THis counter indicates the average number of seconds a data page to remain in cache. Ideally, we have read multiple blogs to consider 300 or more as acceptable value but this value varies depending on your system configuration.

The ideal value is more than 300 but always compare this value with your system configuration. Higher the better concept is also applying here.

SQL Server: Buffer Manager: Free List Stalls/sec

This counter also shows a sign of memory pressure or insufficient memory on your server. This displays the number of requests per second where data requests stall because there are no buffers available. Any value greater than two indicates that SQL Server needs more memory.

SQL Server: Buffer Manager: Lazy Writes/sec

This counter tells about total number of Lazy writer performed in a second.  It means total number of times Lazy Writer process moves dirty pages from the buffer to disk. A lower number is better than a higher number. If value of this counter shows higher value continuously more than 20, then we need to add more memory to the system or we should think about optimizing memory intensive operations.

SQL Server: Buffer Manager: Checkpoint Pages/sec

This counter monitors the number of dirty pages per second, which are flushed to disk when SQL Server invokes the checkpoint process. High values for this counter may indicate memory pressure or insufficient memory.

SQL Server: Memory Manager: Memory Grants Pending

This counter shows the number of processes waiting for memory grant per second. Any value higher than zero indicates a lack of memory. We can also get this information by using a DMV sys.dm_exec_query_memory_grants. Those processes who are waiting to be granted the required memory will show you waiting with RESOURCE_SEMAPHORE wait type. I have explained about resource semaphore wait type in below attached article.

• Fix RESOURCE_SEMAPHORE Wait Type in SQL Server

Here, I have described top 10 performance counters to identify SQL Server memory pressure on your database server. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 833: SQL Server has encountered 32 occurrences of I/O requests taking longer than 15 seconds to complete.
• Disk and Performance Impact of running Online Index Rebuild Operation
• Understanding ASYNC_IO_COMPLETION Wait Type

The post Top 10 Performance Counters to Identify SQL Server Memory Pressure appeared first on Techyaz.com.

Error 701, Severity: 17, State: 193.
There is insufficient system memory to run this query.

Or

Error 802, Severity: 17, State: 20
There is insufficient memory available in the buffer pool.

Error 701 or Error 802: Root Cause

If SQL Server is running out of memory and has no more memory available to allocate to its transactions then it will generate SQL Server memory error 701 or error 802. SQL Server Memory pressure or insufficient memory issue can be raised due to huge data load or other memory intensive operations.

We should check DBCC MEMORYSTATUS output to get latest snapshot of current memory status of the SQL Server. This command is very useful in troubleshooting memory issues in SQL Server. You might even have failed to run this DBCC command because system does not have enough memory. You need to reduce some memory pressure by stopping or killing some processes and then try to run this command to gather in depth information about SQL Server memory state.

The transaction that failed due to memory pressure and generates error 701 or error 802 might be or might not be the cause of this error. We should analyze the trends to reach on any conclusion.

Solution

There are mainly two reasons behind getting SQL Server memory issues for most of the SQL Server systems. Either your server has less memory to handle the current day to day workload or you are running some of the adhoc transactions that will require more memory for their execution like huge bulk data load, complex reports etc. If your SQL Server is running with insufficient memory during day to day activities then you should seriously evaluate the total workload and propose optimum memory size that can handle your current workload.

If you are planning to run any heavy ad hoc transaction then you should temporary increase the memory that can handle the transaction smoothly or you should run such transactions on a server that are built to handle such loads. You should also consider to reduce the batch size that is optimum for your system.

SQL Server is memory intensive application. We need to plan memory sizing for a server after proper evaluation of server state and overall load that will run on that SQL Server instance. But if you are facing memory issue on one of your SQL Server then first we need to troubleshoot it and find the root cause of this memory pressure. Here I am giving you step by step method to find the actual culprit that are causing the memory issue and possible solutions that can reduce some memory overheads.

First Make sure your SQL Server instance is running on dedicated server and not with other applications. If other applications are also using your database server then make sure they are not eating most of the memory. And, If most of the system memory is taken by other applications then you need to seriously think about migrating those application from this database server.

If you cannot migrate these applications to another server then workaround for such issues are to allocate the maximum memory value to your SQL Server instance. You can do it either by using sp_configure or using GUI. Read attached article to change max memory value for your SQL Server instance.

• Understanding SQL Server Memory Allocation and Role of MIN/MAX Server Memory Configuration

Next thing you should check is the server memory configuration. Check below SQL Server memory configuration parameters:

• max server memory
• min server memory
• min memory per query

Notice any unusual settings and fix them as necessary. All above three options have been covered in detain in above attached article.

Now, check the workload in terms of number of concurrent sessions, currently executing queries along with their memory grants. You should also focus on SQL Server transactions that are seeking huge memory values. Look at the transactions and gather a report for high memory intensive operations. Evaluate them and if possible optimize them so that they can take minimum memory.

• Understanding Memory Wait type Resource_SEMAPHORE and how to fix it?

You can also run below DBCC commands to free several SQL Server memory caches. This will also help you and make some relief for your current running transactions but in longer run it will not help if your system will need more memory to proceed the transactions.

• DBCC FREESYSTEMCACHE
• DBCC FREESESSIONCACHE
• DBCC FREEPROCCACHE

Another effective way to look in to memory status is by getting the output of DBCC MEMORYSTATUS command. You would get a good starting point to look in to culprit memory consumers.

We can also start collecting performance monitor counters for memory. Perfmon counters like the value of SQL Server: Buffer Manager\Buffer Cache Hit Ratio, SQL Server: Memory Manager and Page Life Expectancy will be very helpful in identifying memory pressure on SQL Server system. Analyze the trend for these counters and then decide whether issue is coming during some specific operations or system is continuously facing memory pressure.

Based on these analyses you can choose to either increase the system memory, increase the SQL Server memory allocation or reschedule some of the memory specific transactions to the off hours when load is minimum on the system. You can also reduce the batch size of the transaction to reduce the memory pressure. This will be certainly helpful in troubleshooting memory issues.

It is not necessary that your transactions are poorly designed always that is why SQL Server is taking lot of memory to process it. Sometimes even our systems on which SQL Server runs might have problem that end up with memory pressure. So you should consider all these points while fixing any performance issue.
I hope you like this article. Please follow us on our Facebook page and Twitter handle to get latest updates.

Read More:

• 4 Usages of DBCC SQLPERF in SQL Server
• Manage Transaction Log File during Bulk Data Load
• How to Improve Bulk Data Load Performance?
• Overview of SQL Server Performance Tuning
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

The post SQL Server Error 701: There is Insufficient System Memory to Run this Query appeared first on Techyaz.com.

1. Excellent – You Disk Subsystem is responding perfectly for respective counter.
2. Good – You Disk Subsystem is responding fairly for respective counter and you can consider it good considering your workload and other resource utilization.
3. Poor – You Disk Subsystem is not responding well for respective counter and it requires your intervention to drill down more to understand the reason behind slowness.

If you want to read about CPU and Memory related performance counters then i would suggest you to go through with below attached articles.

• Top Perfmon Counters to Identify SQL Server CPU Bottleneck
• Top 10 Perfmon Counters to Identify SQL Server Memory Pressure

Below are the list of important perfmon disk counters that we will be discussing in this article.

• Average Disk Sec/Read
• Average Disk Sec/Write
• Average Disk Sec/Transfer
• Average Disk Queue Length
• Current Disk Queue Length
• Disk Read/Sec and Disk Write/Sec
• %Disk Time
• %Idle Time

Average Disk Sec/Read

Average Disk Sec/Read is important perfmon disk counter that shows the average time in seconds needed to read data from disk and better explain the disk latency. We can find these counters at the logical and physical disk object level. The value for this counter is generally the number of seconds it takes to do each read. The shorter the time needed to read or write data, the faster the system. If you constantly get this counter value more than 20ms then it means your disk is not performing well.

Your disk performance is:

• Excellent, if the value of this counter is less than 6 milliseconds (0.006 sec)
• Good, if the value of this counter is up to 15 milliseconds (0.015 sec)
• Poor, if the value is constantly more than 15 milliseconds (0.015 sec)

Average Disk Sec/Write

Average Disk Sec/Write is also an important counter that shows the average time in seconds needed to write data to disk. that can better explain the disk latency. This counter can be tracked at the logical and physical disk level. The value for this counter is generally the number of seconds it takes to do each read. The shorter the time needed to read or write data, the faster the system. If you constantly get this counter value more than 20ms then it means your disk is not performing well.

Your disk performance is:

• Excellent, if the value of this counter is less than 6 milliseconds
• Good, if the value of this counter is up to 15 milliseconds
• Poor, if the value is constantly more than 15 milliseconds.

Average Disk Sec/Transfer

Average Disk Sec/Transfer is a time that measures average latency for read or write operations. If the Average Disk Sec/Transfer value increases, this indicates that the I/O subsystem is not optimally keeping up with the I/O demand. This counter is available under Logical Disk and Physical Disk object. If you are keeping a watch on this counter make sure to have a look at above perfmon disk counters Average Disk Sec/ Read and Average Disk Sec/Write as well because Average Disk Sec/Transfer is the average of both read and write counters so you need to find out high value is due to read operation or write operation. Below are the values that will tell you whether your disk is performing excellent, good or it is performing slow and requires your intervention to improve its performance.

Your disk performance is:

• Excellent, if the value of this counter is less than 6 milliseconds
• Good, if the value of this counter is up to 15 milliseconds
• Poor, if the value is constantly more than 15 milliseconds.

Average Disk Queue Length

Average Disk Queue Length counter shows you the average number of read and write requests that were queued on the selected physical disk. If this value is exceeding its threshold frequently then we should also look at other perfmon disk counters Average Disk Read Queue Length and Average Disk Write Queue Length. This way you can diagnose whether Average Disk Queue Length is high due to high read or high write operation. The recommended value for this counter is less than 2 per individual disk so if you have multiple disks then your recommended value for Average disk queue length would be twice the no of disks.

Be careful when using thresholds of 2 with SQL Server and SANs.  This value can be much higher than 2 if you have multiple disks.  Let’s say you have 6 drives and Average disk queue length counter is showing around 12, then you should consider your Average disk queue length value 9/6 = 1.5 not 9.

Your disk performance is:

• Excellent, if the value of this counter is less than 1.5 per drive.
• Good, if the value of this counter is up to 2 per drive.
• Poor, if the value is constantly more than 2 per drive,

Current Disk Queue Length

Current Disk Queue Length is the number of disk requests that are currently waiting as well as requests currently being serviced. The difference between average disk queue length and current queue length is CDQL tells current load whereas ADQL tells load during a given time frame. The Current Disk Queue Length metric in Windows Performance Monitor is available for both physical and logical disk. The Current Disk Queue Length value should be less than 2 per disk.

Your disk performance is:

• Excellent, if the value of this counter is less than 1.5 per drive.
• Good, if the value of this counter is up to 2 per drive.
• Poor, if the value is constantly more than 2 per drive.

Disk Read/Sec and Disk Write/Sec

Disk Reads/Sec and Disk Writes/Sec show you the number of read and write operations happening per second on the disk. If you want to set the benchmark for disk capacity then you can determine it by gradually increasing the load on the system.

Your disk performance is:

• Excellent, if the value of this counter is less than 75% of total disk capacity.
• Good, if the value of this counter is up to 85% of total disk capacity.
• Poor, if the value is constantly more than 85% of total disk capacity.

%Disk Time

%Disk Time counter tells how busy the disk is in performing read and write operations. You can see its values normal even your disk has serious disk performance issue. You should compare its value with current/average disk queue length before reaching on any conclusion about disk issue.

Your disk performance is:

• Excellent, if the value of this counter is less than 75% of total disk capacity.
• Good, if the value of this counter is up to 85% of total disk capacity.
• Poor, if the value is constantly more than 85% of total disk capacity.

%Idle Time

%Idle Time measures the percentage of time the disk was idle during the sample interval. The disk is idle when it’s not processing read and write requests. If you are constantly getting its value less than 40% then you can either move some applications from your machine to another machine if you are running other applications as well apart from SQL Server or You can change the current disk system with a faster disk system.

Your disk performance is:

• Excellent, if the value of this counter is greater than 60% of total disk capacity.
• Good, if the value of this counter is greater than 50% of total disk capacity.
• Poor, if the value is constantly less than 40% of total disk capacity.

Related Articles:

• Disk and Performance Impact of running Online Index Rebuild Operation
• How to fix IO error: SQL Server has encountered N occurrence(s) of I/O requests taking longer than 15 seconds to complete.
• Improving Bulk Data Load Performance in SQL Server
• Understanding ASYNC_IO_COMPLETION Wait Type

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters appeared first on Techyaz.com.