VMware Cloud Community
PJSWAN
Contributor
Contributor

ESXTOP and Windows 2008 Resource Monitor Different Stats

Hi, there. Need some input.

Have a SQL 2008 R2 server running on a vSphere 4.1 U2 VM. DBA's are complaining about slow response times on disks.

What I picked up is that ESXTOP gives me the stats below.

CMD/s: 380

MBWRTN/s: 304

DAVG/cmd: 14.06

GAVG/cmd: 14.07

When viewing Disk Response times in Windows Resource Monitor I see very bad response times on the disk.

It will be writing at 33MB/s with a response time of 100 to 200 ms.

This does not make sense to me at all. According to VMWare ESXTOP the latecny is not that high, but Windows are saying it is. Could it have anything todo with the SCSI Contoller type use in Windows. Currently its LSI Logic SAS. Will changing it to a PVSCSI help? Seems to me this is a Windows issue.

Reply
0 Kudos
2 Replies
rickardnobel
Champion
Champion

PJSWAN wrote:

When viewing Disk Response times in Windows Resource Monitor I see very bad response times on the disk.

Does the database admins experience that the performance is bad or is it only the Resource Monitor that reports this?

Have you used Performance Monitor counters for physical disk, like Avg. Disk sec / read and Avg. Disk sec / write.

My VMware blog: www.rickardnobel.se
Reply
0 Kudos
smokey71
Contributor
Contributor

Hey PJSWAN,

There could be a couple issues in regard to your situation. One could be a network issue that's causing latency between your VM and Storage. Depending upon the storage solution (iSCSI, NFS, FC), something as simple as performing a vMotion might do the trick if your hosts storage link is saturated. Something else that you may want to check is the storage interfaces. Its possible that disk response times are okay but the storage interfaces are under duress. Does the storage array report high CPU utilization?

Also, due to storage vendors and their propensity to thin provision or provision on demand, a storage vMotion may be in order. That would essentially defgrag your DB by moving it in its entirety to a new datastore/LUN/export.This should decrease disk response times if this is indeed the problem.

Last but not least; is anything else sharing the physical storage arrays disks besides the SQL DB? If so, you might want to consider giving the SQL DB its own LUN/export to ensure its receiving the IOPS it needs. Separating the DB/Transaction Logs is also a good idea as well.

1) Storage Arrary CPU utilization high?

2) Storage Array interface utilization high?

3) ESX hosts NIC utilization high?

4) Are the SQL DB storage array disks being shared with other VMs?

5) Are you using storage thin provisioning?

Hope this helps

PS- PVSCSI does provide more IOPS if you need it. Question is, do you need it?

Reply
0 Kudos