Post reply

TempDB Data Files - I/O Requests Taking Longer Than 15 Seconds To Complete

  • June 24, 2014 at 7:02 am

    #308482

    Hi,

    Here's a little background of my environment. I am running SQL Server 2008 R2 SP2 64-bit on a two-node Windows Server 2012 R2 cluster. The storage is an Equallogic group consisting of one PS6100XS (hybrid SSD/10k SAS hard drives in RAID 6 Accelerated) and two PS6000E arrays.

    I have noticed that I get several messages in the SQL logs pertaining to "SQL Server has encountered ##### occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [x:\TempDB Data\tempdbxx.xDF] in database [tempdb] (2). The OS file handle is 0x00000000000000E3C. The offset of the latest long I/O is: 0x000001159d0000." It only occurs when I execute an UPDATE STATISTICS WITH FULLSCAN on large tables.

    The database used to be on PS6000XV (15k SAS drives) in RAID 10 with a PS6000E and PS61000E and the servers were Windows Server 2008 R2. There was no issue in that setup. I also only had six data files with T-1118 enabled.

    I have opened a ticket with Dell Equallogic and they seem to think that it's not a SAN issue. I have added more tempdb data files from eight to 12 and enabled T-1118. I don't know if it matters, but all of the data files are 20GB each. I have disabled Delayed ACK and Nagle's Algorithm and it has helped a little.

    Does anyone happen to know what the issue could be? Would I need to increase my tempdb data files to 16? I thought the issue is with the SAN...

    Please help!

    My Blog!

  • June 24, 2014 at 8:23 am

    #1724351

    Adding more TempDB files will help with SGAM and PFS page contention. I would start with this post[/url] to make sure that you are not seeing contention during the operation.

    I would also gather some additional information (latency) on the tempdb files using sys.dm_io_virtual_file_stats. Also gather some perfmon counters (Physical Disk:Avg. Disk sec/read, Physical Disk: Avg. Disk sec/Write) just to have some data for Dell when you call them. Do you still have the old system (where you didn't have this issue)? If so run the operation over there too with the same counters and compare and share that with Dell.


    Microsoft Certified Master - SQL Server 2008
    Follow me on twitter: @keith_tate

    Forum Etiquette: How to post data/code on a forum to get the best help[/url]

  • June 24, 2014 at 8:35 am

    #1724358

    Have a look at this post. It doesn't pinpoint the issue or explain how to resolve it, but gives some pointers where to look.

    Regards

    Lempster

  • June 26, 2014 at 6:42 am

    #1725035

    Thank you for your responses.

    I do have the old SAN as that site is now the backup/mirror site. I don't think a lot of the users would like it as most of them are on the prod site in a faraway location (which would make everything slower for them since they have to go over the shady WAN (we're supposed to have 45 Mbps, but we're getting much worse bandwidth which is an ongoing fight with the ISP)). Maybe I can dig up some old PerfMon counters...

    I have sent the PerfMon counters over and I've seen it as high as 100,000 for Avg Disk Queue Wait for Writes. Their recommendation is creating another LUN and moving six tempdb data files to that LUN. After thinking about it, it really won't change anything since both tempdb data LUNs would be on the same SAN, would it? This is on a cluster so I really would like to make sure that that is the correct approach and not just trying anything that comes to mind. 😛

    My Blog!

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply