Comments on: SQL SERVER – PAGEIOLATCH_DT, PAGEIOLATCH_EX, PAGEIOLATCH_KP, PAGEIOLATCH_SH, PAGEIOLATCH_UP – Wait Type – Day 9 of 28

By: SQL SERVER – Weekly Series – Memory Lane – #015 « SQL Server Journey with SQL Authority

Sat, 09 Feb 2013 01:31:25 +0000

[...] PAGEIOLATCH_DT, PAGEIOLATCH_EX, PAGEIOLATCH_KP, PAGEIOLATCH_SH, PAGEIOLATCH_UP – Wait Type – Day… [...]

By: Darin Beard

Darin Beard — Mon, 23 Jul 2012 19:16:00 +0000

Dave, it seems almost every SQL search I type into Google, it brings me to you. Thank you for all your sharing. It has helped me countless times.

By: Nakul Vachhrajani

Nakul Vachhrajani — Sat, 10 Dec 2011 14:51:00 +0000

What I liked most about this post is the start – it’s the absolute truth, and nothing but the truth!

We use virtualiazation in our development & QA environments. Once, we restored a database of around 50GB, and our servers simply stopped processing our queries. The nightly jobs ran for 3 days and the application ended up in timeouts. We looked at the wait stats and came across not one, but two PAGEIOLATCH stats – PAGEIOLATCH_EX and PAGEIOLATCH_SH.

We informed our IT, and instead of looking at our data, they increased the processor and memory allocations. Their reasoning – they have the best of the line hardware, and no application should require to use more!!!!

When that did not fix it and we escalated matters, they deployed complex monitoring, and guess what? – we got a brand new IO subsystem for our Virtual Machines within 2 weeks!

By: Kush

Kush — Thu, 01 Dec 2011 19:50:47 +0000

I have also found PageIOLatch_SH wait type in my long running queries. I checked perfmon and found that in avg.DiskQueLength counter avg value is 10 – 14. Is that because of I/O bottlenecks. If yes then which hardware need to be update?

By: Rakesh Tiwarekar

Rakesh Tiwarekar — Wed, 20 Jul 2011 13:52:44 +0000

Hi Pinal,

I use the third party backup tool to take compressed backups and the backup is transferred to some backup server through FTP tasks scheduled in windows tasks. when monitored with Memory : Page Faults/Sec in perfmon i have observed that the counter value is near 80-100 when backup occur and while transfer it is 100 consistently. Normally the value fluctuates between 40-100.
My server is configured with 49136MB page file,32GB ram and 8 logical CPU.
CPU utilization is near 75-95% Any suggestions to reduce the page faults/sec count would be much helpful

By: TimB

TimB — Mon, 21 Feb 2011 21:22:27 +0000

I was having problems and this article was very helpful.

What do you mean by “Consistent higher value, Benchmark” under your second point under memory related counters? How do I know what is the benchmark?
SQLServer: Memory Manager\Memory Grants Outstanding (Consistent higher value, Benchmark)

Thank you!
TimB

By: SQLmaster

SQLmaster — Fri, 11 Feb 2011 16:00:50 +0000

Tip: By all means the Disk I/O & Memory are key indicators to cause the performance issues where the wait types will highlight the cause, so keeping a close watch on these factors will help to reduce the problem and then jump into QUERY tuning.

By: Ivan Donev

Ivan Donev — Wed, 09 Feb 2011 20:20:52 +0000

I would additionally adhere to the point of proper placing of files by adding and the factor of file and page contention. In my practise I have seen for example tempdb which under heavy file contention is making SQL Server unresponsive and slow. So I would add to that point and considering splitting a database to different files (this is especially valid for tempdb, where there is an official reccomendation from Microsoft why to do so)

By: weicco

weicco — Wed, 09 Feb 2011 07:28:04 +0000

I’ve found this article good when trying to determine if there’s I/O problems with the server, be it Sql Server or any other server.

http://technet.microsoft.com/en-us/library/cc966540.aspx

If you scroll down to where it says I/O Bottlenecks you’ll see list of 6 items in it. I think that’s a good starting point. Fire up Performance Monitor and monitor your disks while Sql Server is under load.

“If your disk queue length frequently exceeds a value of 2 during peak usage of SQL Server, then you might have an I/O bottleneck.”

One of our server had queue length 10-18 during peak usage. That was enough for me to announce that we are having I/O problems ;)

-Marko