Enterprise storage arrays from vendors like Dell EMC, NetApp, and Pure Storage are the foundation of mission-critical IT environments. Ensuring these systems deliver consistent, high performance under real-world workloads is essential for application reliability and business continuity. In this post, we’ll explore how to benchmark enterprise storage using two industry-leading tools- Fio and Vdbench– with practical configuration examples and best practices.
Why Benchmarking Enterprise Storage is Unique
Enterprise arrays are not just fast disks-they’re complex systems with:
Benchmarking these systems is different from testing a single SSD or HDD. You must simulate production-like workloads, test at scale, and observe performance under both normal and failure conditions.
Best Practices for Enterprise Storage Benchmarking
Simulate real-world workloads: Use realistic mixes of random/sequential I/O, read/write ratios, and block sizes.
Test at scale: Ensure test data sets exceed cache sizes and run with sufficient concurrency.
Run long-duration tests: Observe steady-state performance, not just short-term cache hits.
Monitor the full stack: Track storage, network, and server metrics.
Document everything: Record hardware/software versions, configurations, and test parameters.
Include failure scenarios: Simulate controller or network failures to test resilience.
Fio: Flexible I/O Tester
Fio is a versatile, scriptable tool ideal for generating a wide range of I/O workloads against enterprise storage.
Example Fio Job File for Enterprise Storage
text[global] ioengine=libaio direct=1 rw=randrw rwmixread=70 bs=8k iodepth=64 numjobs=8 size=100G runtime=3600 time_based group_reporting filename=/dev/sdx # Replace with your LUN or device
[verify] verify=crc32
What this does:
Simulates a 70% read/30% write random workload with 8KB blocks.
Runs 8 parallel jobs with a queue depth of 64 for 1 hour.
Uses direct I/O to bypass the OS cache.
Verifies data integrity with CRC32.
Run it with:
sudo fio enterprise_test.fio
Tips:
Use multiple devices or files to simulate multi-volume workloads.
Adjust concurrency (numjobs, iodepth) to match your environment.
Use --output-format=json for detailed reporting.
Vdbench: Enterprise Workload Generator
Vdbench is designed for complex, multi-host enterprise storage validation and offers granular workload definition and data validation.
Example Vdbench Configuration
text# Storage Definitions for multiple LUNs sd=sd1,lun=/dev/sdb,size=100g,openflags=o_direct sd=sd2,lun=/dev/sdc,size=100g,openflags=o_direct sd=sd3,lun=/dev/sdd,size=100g,openflags=o_direct sd=sd4,lun=/dev/sde,size=100g,openflags=o_direct
# Workload Definition: 67% read, 33% write, 8KB random wd=wd1,sd=(sd1-sd4),xfersize=8k,rdpct=67,seekpct=100
# Run Definition: max I/O, 24 hours, 1s reporting rd=rd1,wd=wd1,iorate=max,elapsed=86400,interval=1
Run it with:
vdbench -f enterprise_vdbench.conf
Advanced tips:
Use the hd section to define multiple hosts for distributed testing.
Simulate failures (e.g., disconnect a path or controller) during the run to observe failover behavior.
Use fsd and fwd for NAS/file workloads.
Key Steps for Success
Profile your workload: Know your application’s I/O patterns. (capture the workload IO pattern)
Prepare your environment: Use dedicated test LUNs/volumes.
Configure your tools: Use Fio or Vdbench job files that match your workload.
Run and monitor: Capture storage, host, and network metrics.
Analyze results: Look for steady-state performance, latency spikes, and the impact of failures.
Document and repeat: Ensure tests are reproducible and results are transparent.
Conclusion
Benchmarking enterprise-class storage is about more than just peak numbers-it’s about understanding how your array performs under pressure, during failures, and with your real workloads. Tools like Fio and Vdbench provide the flexibility, power, and validation features needed for accurate, actionable results. By following best practices and using realistic configurations, you can ensure your storage infrastructure is ready for the demands of the modern enterprise.
I have been using HammerDB for database performance bench-marking . This is very useful tool if you’re getting into any proof of concepts (POC) or testing of new database infrastructure stack before production roll-out.
In this blog post we will discuss around using HammerDB to generate OLTP (TPC-C workload) on Microsoft SQL database. In my example I had Microsoft SQL and HammerDB server created on AWSEC2 instances. But from HammerDB perspective it doesn’t matter as far as it can communicate to database instance.
We will follow 5 simple steps to run synthetic workload on MS SQL database. So let’s get started.
Step 1 – Installing the HammerDB Application
Before you get started make sure that –
HammerDB and MS SQL server are on same network/VLAN
MS SQL server is installed and running
Login to MS SQL console and create new SQL database. Make sure that new database is created on the target storage disks. If you create database in C drive, then you might not get expected performance due to disk bottleneck.
Microsoft SQL database console
Download HammerDB installer (Click image below)
HammerDB download link
Once HammerDB installer is downloaded, go ahead and install the same. Below are the links for installation steps.
MS SQL server ready with test database created on desired target storage disks
HammerDB installed and running
Step 2 – Configuration of Schema Build
We will need to created OLTP workload schema as per TPC-C specifications. Follow below steps for building OLTP schema on target database
Open the HammerDB console
HammerDB – Console
Under Benchmark navigation page, double-click on SQL Server. In Benchmark Options pop-up window select SQL Server and TPC-C options. Then click Ok. Click Ok once again to confirm the selection.
HammerDB – Selecting SQL database and TPC-C workload
Under Benchmark navigation now you can see SQL Server selected with TPC-C options.
HammerDB – SQL server and TPC-C benchmark
Expand TPC-C under SQL Server and then expand Schema Build
HammerDB – TPC-C Schema Build
Double-click on Options under Schema Build. Pop-up window of TPC-C Build Options will open. In this window enter below details, and then click Ok
SQL Server – IP address or hostname of SQL server. Keep (local) if HammerDB is installed on the SQL server.
Authentication – Use Windows Authentication if you want logged-in user credentials to be used for SQL server, else select SQL authentication and enter credentials.
SQL Server Database – Name of the database which we had created in Step 1
Number of Warehouses – Enter the value to number of warehouses you have chosen for your testing. Preferably select number of warehouses equal to number of cores on the server
Virtual Users to Build Schema – Set this value equal to number of warehouses.
HammerDB – TPC-C Build Options
In the Benchmark pane double-click on Build
HammerDB – TPC-C Schema Build
Click Yes to confirm creating schema in the target SQL database.
HammerDB will now start creating virtual user threads and create schema in the target database. This process takes some time. You can monitor the status in top-right corner of HammerDB console. (TPC-C creation in top-right)
HammerDB – TPC-C Schema Creation in process
Once completed you can see that the status is changed to Complete
HammerDB – TPC-C Schema Creation Completed
Step 3 – Configure DriverScript
Follow below steps to configure HammerDB driver script
Expand the Driver Script from Benchmark navigation pane and double-click on Options
HammerDB – Driver Script
In the TPC-C Driver Options pop-up window enter below details, and then click Ok
SQL Server – Keep it same as Step 2
Authentication – Keep it same as Step 2
Total Transactions Per User – Keep default value. This value will set the number of transactions each virtual user will process before logging off
TPC-C Driver Script – Keep this option as Timed Driver Script. This will run the workload for finite time as specified in Minutes for Test Duration
Minutes of Rampup Time – The rampup time defines the time in minutes for the monitoring virtual user to wait for the virtual users running the workload to connect to the database. 2 minutes in my case. You can increase this number if you’ve higher number of virtual users.
Minutes for Test Duration – The Minutes for Test Duration is shown as duration in the Driver Script. This does not include rampup time.
Use All Warehouses – Keep this option checked.
HammerDB – Driver Script Options
In the Benchmark navigation double-click on Load (under Driver Script). You need to Load the Driver Script every time you make changes to Driver Script Options.
HammerDB – Driver Script Load
Step 4 – Create Virtual User
Once HammerDB driver script is loaded, follow below steps to create virtual user.
Expand Virtual User from Benchmark pane
HammerDB – Virtual User
Double-click on Options. In the pop-up window enter below details, and then click Ok.
Virtual Users – Keep number of users same as Step 2
Keep Other inputs as default
HammerDB – Virtual User Options
In the Benchmark navigation pane double-click on Create under Virtual User. This will create virtual users and keep them idle.
HammerDB – Virtual User Create
At this point we are ready to start OLTP workload on target database.
Step 5 – Run HammerDB OLTP (TPC-C) Workload
Follow below steps to run the OLTP workload and monitor the TPMs.
In Benchmark pane double-click on Run (Under Virtual User).
HammerDB – Run OLTP (TPC-C) workload
Now Virtual Users will start logging into the target database and begin running their workload. You can monitor the status under Virtual User 1-MONITOR
HammerDB – Starting OLTP (TPC-C) Workload – In Progress
While workload is running you can monitor the real-time TPM (Transactions Per Minute) by clicking on Transaction Counter
HammerDB – Transaction Counter
Once workload is completed you can see the status in top-right corner as well as under Virtual User 1-MONITOR
Once the workload is completed note down TEST RESULT under Virtual User 1-MONITOR
HammerDB – OLTP (TPC-C) TEST RESULT
You can run multiple tests and take average across them for realistic performance numbers.
Apart from MS SQL (used in this blog post) HammerDB supports running OLTP (TPC-C) and OLAP (TPC-H) on Oracle, IBM DB2, MySQL, PostgreSQL, MariaDB and Redis.
DEllEMC’s XtremIO has simple, easy-to-use management. The XtremIO Management Server (XMS) delivers an HTML5 user interface that is a simple and easy-to-use interface for storage administrators. XMS allows storage administrators the ability to provisions storage with very little setup and planning.
Hope this post is helpful to all Oracle users trying to get best out of their XtremIO investments.
XtremIO is designed and optimized for databases and for DBAs, providing the following benefits.
Predictable Performance
XtremIO provides predictable and consistency low-latency performance
With XtremIO scale-up and scale-out architecture, year-to-year growth is easy. The initial investment is preserved and application performance is improved.
Performance is predictable and provides best response times regardless of the workload and environment – be it production, QA, test or development
Incredible Simplicity
With XtremIO, there is no need for planning and tuning the location and number of database files
All DBA tasks are fast and simple with 1 to 3 steps
Agility
The typical enterprise applications require multiple copies such as test/development, reporting or online analytics. DBAs and test/dev engineers often have to spend hours managing the DB creation and refreshing the environments while often being limited by capacity, performance, and the number of copies.
These copies can be repurposed for near real-time analytics, test/dev and any other use case- all with complete space efficiency.
Protection
Protecting the database is easy with XtremIO
There is no need for any design covering RAID type, data file capacity, load balancing, and tuning.
The data is protected with a proprietary flash-optimized algorithm called XtremIO Data Protection (XDP).
XDP is very different from RAID in several ways. Since XDP is always working within an all-flash storage array, several criteria were important in the design of this protection scheme. XDP benefits include ultra-low capacity overhead, high levels of data protection in case of double SSD failure, rapid rebuild times, flash endurance, and of course extreme performance
With XtremIO virtual copies it is easy to protect and recover from any operational and logical corruption; XVC’s allow the creation of frequent point-in-time copies (according to RPO intervals – seconds, minutes, hours) and use them to recover from any data corruption
An XVC can be kept in the system for as long as needed. Recovery using XtremIO virtual copy is instantaneous and does not impact system performance.
Irrespective of using any application/database with XtremIO storage array below listed general guidelines are common.
Keep consistent, duplex link speed on all paths between the host and the XtremIO cluster
To ensure continuous access to XtremIO storage during a cluster software upgrade, verify that minimum I/O timeout of 30 seconds is set on the HBAs of all hosts connected to the affected XtremIO cluster. Also, verify that a minimum timeout of 30 seconds is set for all applications that are using storage from the XtremIO cluster.
The HBA queue depth (also referred to as execution throttle) controls the amount of outstanding I/O requests per HBA port. The HBA queue depth should be set to the maximum value
The LUN queue depth controls the amount of outstanding I/O requests per single path. These settings are controlled in the driver module for the card at the OS level. When connecting Linux host to XtremIO, a LUN queue depth setting should retain its default values.
I/O scheduling controls how I/O operations are submitted to storage. Linux offers various I/O algorithms (also known as “I/O Elevators“) to accommodate the different workloads. When connecting a Linux host to XtremIO storage, set the I/O elevator to either noop or deadline. It is not recommended to use the cfq I/O elevator setting, as it’s less optimal for XtremIO storage.
It is HIGHLY RECOMMENDED to follow the latest “XtremIO Host Configuration Guide” for all operating system which will use storage from XtremIO
If DB is virtualized then make sure all Virtual Machine components are provisioned from XtremIO storage (OS, Application/Binary, Swap, Paging, etc.)
2. Oracle ASM
Oracle Automatic Storage Management (ASM) is Oracle’s recommended software for supporting Oracle database files.
For more information on ASM please refer this link
ASM General Recommendation
External redundancy is recommended for XtremIO
The XtremIO Storage Array natively provides flash-optimized data protection
Database Files Location in ASM Disk Groups
Best practices for storing Oracle DBMS file types in ASM disk groups are mentioned as below.
Oracle Database Files Location in ASM disk groups
Note: The second REDO data group (DG) is applicable if REDO logs are multiplexed.
Number of LUNs per Disk Group
Excellent cluster performance is achieved using an XtremIO Storage Array with just single LUN in a single disk group. However, in order to maximize performance from a single host, parallelism and adequate utilization of device queues are required.
The best practice to achieve this is by using a minimum of four LUNs for the data disk group. Doing this enables the hosts to use parallelism and ensures optimal performance without any bottlenecks.
The best practices for Disk group configuration and data placement are outlined in the below table.
Number of LUNs per disk group
512 verses 4K Advanced Format Considerations
The default setting for XtremIO volumes is 512 bytes. It is recommended to keep the default setting and not use 4K Advanced Format.
3. Multiblock I/O Request Sizes
Oracle Database performs I/O on data files in multiples of the database block size (db_block_size), which by default is 8KB. The default Oracle Database block size is optimal on XtremIO. XtremIO supports larger block sizes as well. In the case of multiblock I/O one should tune the Oracle Database initialization parameter db_file_multiblock_read_count to limit the requests to 128KB. This is derived with the following formula:
db_file_multiblock_read_count is db_file_multiblock_read_count = 128KB / db_block_size
Usually, Oracle DB is optimized to perform very large transfers to mitigate the seek cost due to multiblock reads on mechanical/spinning drives. In a seek-free storage environment, such as XtremIO, there is no need for such mitigation. Also, most modern FC HBAs require OS to segment large requests into multiple requests. For example, an application IO of 1MB is fragmented by Linux block I/O layer into two 512KB transfers to suit HBA max transfer size.
4. REDO Log Block Size
The default block size for REDO LOG is 512 bytes. I/O requests sent to the redo log files are in increments of the redo block size. This is the blocking factor Oracle uses within REDO LOG files and has nothing to do with the on-disk format of the XtremIO LUN.
XtremIO’s recommendation is to create REDO LOG files with 4K block size. For more details on this please check Oracle Support notes 1681266.1.
Note: For Oracle version prior to 12.2.0.1.0, you should set the parameter _disk_sector_size_override to TRUE when creating a redo log with 4K block size in the database instance.
Do not set the parameter _disk_sector_size_override in the ASM instance. Once the instance is running, simply add more redo logs with the BLOCKSIZE option set to 4KB and then drop any redo logs that have default 512B block size.
5. Grid Infrastructure Files – OCR/Voting
The block size for both Oracle Cluster Registry (OCR) and Cluster Synchronization Services (CSS) voting files are 512 bytes, hence I/O is therefore sized as multiple of 512 bytes. This is consistent with XtremIO’s best practices and hence no changes are needed in OCR/Voting files.
6. Oracle DB Level Compression & Encryption
XtremIO has inline data reduction (deduplication and compression) running all the time without the performance penalty and stores 100% of data in encrypted format using Data At Rest Encryption (D@RE). This makes Oracle DB level compression and encryption as redundant.
XtremIO data services work for all the data stored on arrays, unlike being selective like Oracle. Also XtremIO no not use host CPU for data services, which is an expensive resource in the Oracle environment.
With XtremIO it is a best practice to disable / not use application-level Compression and Encryption services.
XtremIO Advanced Services for Oracle
XtremIO offers a wide variety of use cases to simplify database environment workflow. XtremIO comes along with a tool called iCDM (Integrated Copy Data Management) which allows automating all Copy Data Management (CDM) tasks in DB environments.
Few use cases are mentioned below.
1. Modern Backup-to-Disk using XtremIO XVC
XtremIO XVCs (XtremIO Virtual Copy) are precise point-in-time copies of source volumes which basically are a collection of metadata pointers to the source volume blocks. Therefore, XVC consumes minimal physical capacity.
Executing XVCs is extremely fast and hence most efficient backup-to-disk methodology. The best part is this process does not utilize production/source server resources for creating backup-to-disk copy. Over time as source data is updated/changed, only unique data is stored on XtremIO in compressed format.
2. XtremIO XVC for Manual Continuous Data Protection (CDP)
XtremIO XVCs are so efficient that these can be used as part of a business continuity strategy. Below mentioned two options can be used for this.
Crash-Consistent (or “Restart-able” Image)
A crash-consistent or restartable image is a point-in-time image of the primary database on disk
This option involves taking XVC of the primary database while it is up and operational. The image that is captured is similar to the state of the primary database.
During the DB restart on the XVC, the DB automatically performs a recovery using the online logs.
All committed transactions are included and all uncommitted transactions are rolled back.
Application/DB-Consistent (“Recoverable” Image) –
A recoverable image is a point-in-time image of the primary database on disk
This option involves taking XVC of the primary DB while DB is in “Backup” mode
Highly recommended to have a backup file of the control file prior and after the completion of the XVC process.Unlike crash-consistent copy, data files can be rolled forward in time using logs – up to latest or desired SCN (captured in the control file)
3. XtremIO XVC for Cloning Primary Database (BCV Copy)
BCV / clones of the primary copies can be created using XtremIO XVCs. Methods for clone creation are as mentioned in “2. XtremIO XVC for Manual Continuous Data Protection (CDP)”
operating System Best Practices
When it comes to performance optimization operating system settings also play a major role. It is highly recommended to follow all the operating system best practices as listed in the “XtremIO Host Configuration Guide”.
The absence of host best practices might result in host-bound performance than XtremIO bound performance. In short, the host/operating system might become the bottleneck, because of the host/operating system level queuing.
