Post reply

Bad I/O on C: drive

  • February 20, 2017 at 11:27 am

    #335346

    We have a SQL 2016 on Azure. It's running into bad I/O problems. When I was looking at the resource monitor, I was surprised to see it's the drive C: that has the longest queue for I/O while all other drives barely have any lag. The C: drive has 126 GB total with 95 GB free space. All the db data is on another drive.

    How this could be possible? I thought the bottleneck should be with the data drive.

  • February 20, 2017 at 11:45 am

    #1929404

    I am assuming reading into the question that you have an Azure-based VM.....

    Is your pagefile there on C:?  Have you set MAX MEMORY sensibly in the instance?

  • February 20, 2017 at 12:55 pm

    #1929420

    Are any of the following SQL Server bits installed on C:?

    • SQL Server executables / log files etc?  If so, are you getting a lot of error messages at the moment?
    • SQL Server system databases?  Do you have a lot of frequently-running jobs?  Have you accidentally installed stuff in the wrong databases?
    • Temp DB?  Is it heavily used?  Are you able to move it onto a separate drive?  Can you optimise your heavy-users of TempDB?
    • Are backups going to C:?  Can you get them onto another drive?

    Just a few thoughts...

    Thomas Rushton
    blog: https://thelonedba.wordpress.com

  • February 20, 2017 at 1:42 pm

    #1929436

    Thanks a lot, guys. I think I found out what the problem is. The tempdb right now is on C:, which is where the main i/o outage happens. My plan is to upgrade data drives and move all the system dbs there. 

    While I'm here, is it advisable to consolidate several small servers to a more powerful one? We have a bunch of these meager servers with 2/4 cores and 7/14 GB ram. I personally want to consolidate them, but I'm not quite sure about the performance impact of the consolidation vs isolated servers. These are all new servers we inheritted from a new company acquisition and I'm not sure where the servers' performances stand.

  • February 23, 2017 at 6:36 am

    #1929930

    Michelle-138172 - Monday, February 20, 2017 1:42 PM

    ...These are all new servers we inheritted from a new company acquisition and I'm not sure where the servers' performances stand.

    Once you get the immediate issues sorted, run some baseline tests so you will know what Good and Bad mean for these servers 🙂

    ------------------------------------------------------------------------------------------------Standing in the gap between Consultant and ContractorKevin3NFDallasDBAs.com/BlogWhy is my SQL Log File HUGE?!?![/url]The future of the DBA role...[/url]SQL Security Model in Plain English[/url]

  • February 23, 2017 at 10:48 am

    #1930000

    Thanks, Kevin.

  • February 23, 2017 at 11:20 am

    #1930009

    Kevin3NF - Thursday, February 23, 2017 6:36 AM

    Michelle-138172 - Monday, February 20, 2017 1:42 PM

    ...These are all new servers we inheritted from a new company acquisition and I'm not sure where the servers' performances stand.

    Once you get the immediate issues sorted, run some baseline tests so you will know what Good and Bad mean for these servers 🙂

    Heh... it's on the cloud.  It's all bad. 😉

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 7 posts - 1 through 6 (of 6 total)

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