Performance Tuning Windows 2012: Storage Subsystem – Part 1

In this article we’ll discuss performance considerations for your storage subsystem. When selecting a storage solution you will usually consider the performance, which improves or degrades when considering multiple factors such as cost, reliability, availability and how easy it is to maintain and manage.

There are many factors to consider as storage requests work their way to the actual storage subsystem: cache-management, filesystem architecture, and volume management are all components involved in handling storage requests. They translate application calls into individual access requests, traversing the storage stack and creating a stream of commands that are presented to the disk storage subsystem. The sequence and quantity of those calls can improve or degrade the performance you get out of your storage subsystem.

The driver stack of a storage system includes the following components, that all play a role and can affect performance:

·         File system Drivers – NTFS, FASTFAT

·         Snapshot & Management Drivers – VOLSNAP, VOLMGR, VOLMGRX

·         Partition & Device Classs Drivers – PARTMGR, CLASSPNP, DISK

·         Port Driver – STORPORT, SPACEPORT

·         Adapter Interface Drivers – Miniport Driver

This layered driver model in Windows 2012 (and earlier) sacrifices some performance for the sake of management and ease-of-use.

Selecting Your Storage Solution

Some of the most important considerations when choosing your storage systems are:

·         Understanding your current and future storage workload needs

·         Understanding the requirements of the applications you have in place

·         Determine the storage space, bandwidth, and latency for current and future needs

·         Choosing between striping,  mirroring (or other RAID solution), and determining a backup strategy

·         What procedure you use for data recovery purposes


·         Read vs. Write ratio

·         Sequential vs. random access

·         Typical size of a storage request

·         Storage request concurrency

Estimating the Amount of Data to Be Stored

·         How much existing data will you move to your new server

·         How much new data will you store on the server in the future

In most cases it is save to assume that the growth of your storage needs will be faster in the future than it has been in the past. For example, you can find out if your organization plans to hire many new employees, are large projects being planned, etc.

You must also consider how much space is used by operating system files, applications, redundancy, log files, and other factors. Table 9 describes some factors that affect server storage capacity.


·         Operating system files

At least 15 GB. Plan for an additional 5 GB for the system volume for service packs, updates,etc.

·         Page file

Typically  1.5 times the amount of RAM. If your servers has hundreds of GB of RAM, you might be able to have no pagefile.

·         Memory dump

Physical memory plus 1 MB.

·         Applications

Depends on the application. Contact your application vendor how to calculate storage requirements.

·         Log files

Depends on the applications that create the log file. Some applications let you configure a maximum log file size.

·         Data layout and redundancy

Varies depending on cost, performance, reliability, availability, and power goals.
For more information, see Choosing the Raid Level later in this guide.

·         Shadow copies

The default is 10 percent of the volume, but you might have to increase this based on frequency of snapshots and data updates.

In our next article we’ll look more into choosing a storage solution and take fault tolerance and high availability into consideration.