Solved

VM is on HDD or SSD?

  • 18 August 2021
  • 3 replies
  • 76 views

Hi Folks,

I have some SQL servers running on Nutanix without using ‘Flash’ mode for those. I am facing disk latency alerts for vmdisks on those SQL server VMs. Is there any way to identify if the VM disks are on HDD or SSD?

icon

Best answer by ddubuque 18 August 2021, 15:56

@mikkisse is correct.

Going to the VM and looking at the I/O metrics will give you a lot of information pertaining to Read/Write distribution on disk, as well as the type of writes.  If doesn’t give long term I/O metrics, but if you’re seeing alerts, you can watch this and get an idea of what’s going on.

 

 

Few recommendations as we run numerous MS-SQL servers on AHV and ESX clusters on hybrid clusters.

  1. Take advantage of AHV Turbo.  This helps greatly when you’re on a hybrid cluster especially. 
    1. When you have busy databases that require high I/O, make sure they exist on separate virtual disks.  Doing so on AHV will allow for better CPU consumption and more efficient storage operations.  
      The Wait is Over: AHV Turbo is Here! | Nutanix Community
  2. Make sure you have good indexing jobs.  Not having proper indexes can hurt application performance.
    SQL Server Index Architecture and Design Guide - SQL Server | Microsoft Docs
  3. Make sure that your disks have the correct Allocations.  Most SQL servers need to have their virtual disk formatted to 64k allocation as the majority of reads are between 64-512k.  Having too small or too large of storage chunks written or read at a time can have an adverse effect of storage I/O
  4. If you’re using ESX (VMWare) ensure that Receive Side Scaling is enabled on the network interface.  This will ensure that network traffic coming in and being written is balanced across you vCPU.  Otherwise if you have multiple cores, it may focus writes directly with a single core and lead to constraints.  This is actually a lot more common of an issue than folks realize.  This should always be enabled if you have 2vCPU or more for any Windows system.
  5. Ensure that you’ve provisioned enough RAM to SQL. for example SQL server typically needs about 19% of your total SQL storage. So if you have 100 GB, you should really have 19GB of RAM dedicated to SQL.  Make sure you leave about 4 or more GB of RAM for the operating system as well.
     
View original

This topic has been closed for comments

3 replies

Userlevel 2
Badge +1

Hello!

You can click on VM, select I/O Metrics, scroll down and look at Read Source.

Userlevel 3
Badge +10

@mikkisse is correct.

Going to the VM and looking at the I/O metrics will give you a lot of information pertaining to Read/Write distribution on disk, as well as the type of writes.  If doesn’t give long term I/O metrics, but if you’re seeing alerts, you can watch this and get an idea of what’s going on.

 

 

Few recommendations as we run numerous MS-SQL servers on AHV and ESX clusters on hybrid clusters.

  1. Take advantage of AHV Turbo.  This helps greatly when you’re on a hybrid cluster especially. 
    1. When you have busy databases that require high I/O, make sure they exist on separate virtual disks.  Doing so on AHV will allow for better CPU consumption and more efficient storage operations.  
      The Wait is Over: AHV Turbo is Here! | Nutanix Community
  2. Make sure you have good indexing jobs.  Not having proper indexes can hurt application performance.
    SQL Server Index Architecture and Design Guide - SQL Server | Microsoft Docs
  3. Make sure that your disks have the correct Allocations.  Most SQL servers need to have their virtual disk formatted to 64k allocation as the majority of reads are between 64-512k.  Having too small or too large of storage chunks written or read at a time can have an adverse effect of storage I/O
  4. If you’re using ESX (VMWare) ensure that Receive Side Scaling is enabled on the network interface.  This will ensure that network traffic coming in and being written is balanced across you vCPU.  Otherwise if you have multiple cores, it may focus writes directly with a single core and lead to constraints.  This is actually a lot more common of an issue than folks realize.  This should always be enabled if you have 2vCPU or more for any Windows system.
  5. Ensure that you’ve provisioned enough RAM to SQL. for example SQL server typically needs about 19% of your total SQL storage. So if you have 100 GB, you should really have 19GB of RAM dedicated to SQL.  Make sure you leave about 4 or more GB of RAM for the operating system as well.
     

Thank you mikkisse and ddubuque, I appreciate your responses and the details provided. I will check this.