VMware Cloud Community
Cornishpasty02
Contributor
Contributor
Jump to solution

VMDK size recommendation for IO Analyzer when testing vsan

Hi,

Is there a VMDK size recommendation for Vmware IO Analyzer? When you deploy it from the template the test is run against the second 100mb disk. I've seen some recommendations to delete this second drive and add a new larger one.

Analyzer 01 - 100MB disk, I get 12000 iops, 45 MBps on a 4k_70%read_80%random test.

Analyzer 02 - 100GB disk, I get 1300 iops, 5 MBps on a 4k_70%read_80%random test.

Caching is disabled on all the disks and controllers (HP P420i). 3 x HP DL380 (200SSD, 5 x 900 10kSAS).

I'm surprised at the difference as both the disks should hit the 200GB ssd. Neither of the disks the analyzers are writing to are formatted with any FS. Obviously the second machine with the larger disk is not hitting the read cache hence the lower iops figure but I'm not sure why as the SSD's are large enough.

Thanks

0 Kudos
1 Solution

Accepted Solutions
CHogan
VMware Employee
VMware Employee
Jump to solution

Remember, VSAN is all about having your working set in cache, so that most of the reads hit the flash cache tier.

It seems that analyzer 1 with 100MB is mostly in cache, whereas analyzer 2 is not.

We work off of a guideline, whereby an application's working set is usually 10% of its capacity. Sometimes it is more, sometimes it is less, but 10% is a generally accepted rule of thumb.

I don't know how Analyzer has been configured, but does it's workload contain repeat data patterns, so that some cached data can be read?

If not, it may mean that you are simply filling up the SSD write buffer, destaging it to the spinning disk when it reaches a particular threshold, then filling it up again. This means you are bound by magnetic disk performance and getting very little in the way of benefit from the caching layer of VSAN.

Things to look at:

1. Is Analyzer using all 100GB as its working set, and will this reflect your production workloads? If not, reduce it to a size that is reflective of a real production working set? If most of your VMs use 100GB VMDKs, consider a working set size of 10GB.

2. Is Analyzer using repeat patterns? If not, configure it to do so, or use another benchmark tool that does.

HTH

Cormac

http://cormachogan.com

View solution in original post

0 Kudos
2 Replies
CHogan
VMware Employee
VMware Employee
Jump to solution

Remember, VSAN is all about having your working set in cache, so that most of the reads hit the flash cache tier.

It seems that analyzer 1 with 100MB is mostly in cache, whereas analyzer 2 is not.

We work off of a guideline, whereby an application's working set is usually 10% of its capacity. Sometimes it is more, sometimes it is less, but 10% is a generally accepted rule of thumb.

I don't know how Analyzer has been configured, but does it's workload contain repeat data patterns, so that some cached data can be read?

If not, it may mean that you are simply filling up the SSD write buffer, destaging it to the spinning disk when it reaches a particular threshold, then filling it up again. This means you are bound by magnetic disk performance and getting very little in the way of benefit from the caching layer of VSAN.

Things to look at:

1. Is Analyzer using all 100GB as its working set, and will this reflect your production workloads? If not, reduce it to a size that is reflective of a real production working set? If most of your VMs use 100GB VMDKs, consider a working set size of 10GB.

2. Is Analyzer using repeat patterns? If not, configure it to do so, or use another benchmark tool that does.

HTH

Cormac

http://cormachogan.com
0 Kudos
Cornishpasty02
Contributor
Contributor
Jump to solution

Yes you're right.

IO Analyzer writes to an un-formated drive as it appears blue in iometer, so it uses the whole drive. I've decided on a 10GB second vmdk now, even that is quite a large working set.

Thanks

0 Kudos