HP c-Class Performance Tuning manual Benchmarking through a filesystem

Benchmarking through a filesystem

Issue

Although using a filesystem is necessary for most storage deployments, it involves additional work to access the data stored on the IO Accelerator. These additional lookups decrease maximum system performance when compared to the benchmark results achieved by benchmarking directly on the block device.

Solution

When you are running micro-benchmarks to vet system performance, you should benchmark by accessing the block device directly. Otherwise, use any application-native filesystem implementation, possibly testing a handful where available. HP testing has shown XFS to be reasonably fast under most circumstances. For Linux, HP recommends using the XFS filesystem.

Slow performance using RAID5 on Linux

Issue

The native Linux implementation of RAID5 is verified to have performance issues with the IO Accelerator. The Linux RAID5 configuration is believed to use a single thread/single CPU to perform the needed parity calculations inherent in running a RAID5 system.

Solution

An alternate RAID stack might provide better performance. Additionally, IO Accelerators might be configured to operate in a RAID10 solution.

Using CP and other system utilities

Issue

Most traditional system utilities, such as CP and rsync, are built with slow legacy storage in mind. They do not achieve optimal performance from the IO Accelerator like well-tuned applications.

This is not to say that the IO Accelerator does not work well with standard utilities. It is still much faster than traditional storage using the same utilities, and additional performance benefits will be available in the future as these utilities are optimized for high-performance storage.

Solution

Avoid using traditional system utilities for general benchmarking purposes, as they are not a good representation of peak performance.

ext4 in Kernel.org 2.6.33 or earlier might silently corrupt data when discard (trim) is enabled

CAUTION: HP does not support the use of ext4 in Kernel.org 2.6.33 or earlier. Ext4 in Kernel.org 2.6.33 or earlier might silently corrupt data when discard is enabled.

The ext4 filesystem in the Kernel.org kernel 2.6.33 and earlier contains a bug where the data in a portion of a file might be improperly discarded (set to all 0x00) under some workloads. Use Version 2.6.34 or newer

Debugging performance issues 14