Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Understanding large-scale sequential write performance in VMDKs residing on VMFS datastores (57254)

Last Updated: 11/21/2018Categories: InformationalTotal Views: 5577Language:
English

2 like this article

Subscribe to get an email
newsletter with new updates

2 people found this helpful Please provide article feedback:

Symptoms

When a guest OS drives large amount of sequential write IO to a disk, write performance may differ based on the provisioning type used for the virtual disk. VMware supports three provisioning types:

Thin Provisioned

Thick Provisioned

Eager-zeroed Thick Provisioned

These three provisioning methods will have different performance consequences depending on workload and IO distribution. The largest distinctions are seen in large-scale write IO performance. Depending on provisioning scheme, you may observe a significant performance differential during large-scale sequential write IO operations. In certain circumstances, performance may be significantly lower/degraded in one provisioning scheme versus others. Understanding the distinction between the provisioning schemes for sequential write IO operations will clarify potential performance improvement or degradation when running large-scale sequential write IO operations.

Purpose

This article describes the distinctions between the provisioning methods and their consequences on persistent write performance. Large-scale write IO performance may improve or degrade depending on provisioning scheme.

Resolution

The primary distinction between the three provisioning types surrounds preparation of net new blocks when they are consumed for the first time by a VM. The three provisioning schemes have different default, day zero behavior:

VMDK Provisioning Type

Blocks allocated on creation?

Blocks zeroed on creation?

Thin

N

N

Thick

Y

N

Eager-zeroed Thick

Y

Y

In this context, "allocated" means that the space is marked as in-use by the VMFS filesystem. This guarantees that the blocks promised to the VMDK will be available, and prevents overprovisioning of storage resources. "Zeroed" means that the blocks are all prepared, erased and ready for consumption by the VM. These distinctions can cause difference in write IO performance, as different VMFS filesystem-level steps are required depending on provisioning type. When a VM issues a write to a virtual disk, the block being written may need to go through a preparation phase depending on allocation scheme. All preparation in VMFS is done in 1MiB increments.* This preparation only occurs when a new block is touched for the first time.

New blocks on thin-provisioned VMDKs

The space needed to satisfy the new block is allocated on the VMFS filesystem.

The new block is zeroed by VMFS to ensure consistency.

The new block is ready, and the VM's write is processed. The payload is written to the new block.

New blocks on thick-provisioned VMDKs

The new block is zeroed by VMFS to ensure consistency

The new block is ready, and the VM's write is processed. The payload is written to the new block.

New blocks on eager-zeroed thick-provisioned VMDKs

Not applicable. All blocks are pre-allocated and pre-zeroed when eager-zeroing is used. The payload is written immediately, as there are no net-new blocks.

The preparation steps associated with thin and regular thick-provisioned VMDKs do add some overhead to write operations. During normal production, these are not meaningful and performance is similar across all provisioning types. During large-scale consumption of new blocks, however, performance distinctions may be observable to the end user. As the payload cannot be written until the block is prepared, the payload must wait until preparation is complete before it can be written. When large write operations are initiated by a guest OS, this will involve a large volume of block preparation activities and could result in observably lower performance on thin or regular thick-provisioned disks when performance is compared to eager-zeroed disks.

The degree of any observable performance differential will vary based on numerous factors including:

Overall load level within the compute environment

Load on the storage array

The storage array's handling of zero data

Other factors.

The overheads involved in thin and normal thick-provisioned VMDKs are modest, though at high volume they can become apparent due to these or numerous other factors. The primary external factor (beyond ESXi and VMFS behaviors) in write performance are specific storage array behaviors. Various storage platforms handle zero data differently (such as transparent page compression, thin volume/LUN zeroing behaviors, etc.) and this can cause changes or degradation in end-user performance within VMs. For additional information regarding best practices for provisioning schemes, array-specific handling of zero data, thin volume/LUN preparation or other topics, VMware recommends engagement with the applicable storage vendor for specific guidance.

In general, thin provisioned VMDKs are useful as they enable easier space management and result in less wasted space through vSphere advanced space-reclamation technologies both at the datastore level and within many guest operating systems when thin provisioning is used. Eagerzeroed thick provisioning is typically recommended only for highly latency-sensitive applications or where the allocation/zeroing process overhead should be avoided. This recommendation also may vary depending on array manufacturer recommendations.

* Since VMFS5, all internal VMFS block sizes are 1MiB. In VMFS3, the block size was 1MiB by default, or user-selectable at any doubling between 1MiB and 8MiB.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere ESXi

VMware vSphere ESXi

Related Versions:

VMware vSphere ESXi 6.7

VMware vSphere ESXi 6.5

VMware vSphere ESXi 6.0

VMware vSphere ESXi 5.5

VMware vSphere ESXi 5.1

VMware vSphere ESXi 5.0

Take Our Survey

Support Assistant