Home > Storage > PowerStore > Databases and Data Analytics > Dell PowerStore: Oracle Best Practices > Test the I/O system before implementation
Test I/O bandwidth and IOPS on dedicated components of the I/O path to ensure that expected performance is achieved before creating a database. On most operating systems, testing I/O bandwidth and IOPS can be done using one of the following methods:
Testing could be performed with simple scripts to measure the performance of reading and writing large test files that perform large block sequential I/Os. The tests could be performed using Linux command dd or Oracle ORION. Two large test files should be used with each volume owned by a different PowerStore node. The test verifies that all I/O paths are fully functional. If the resulting throughput matches the expected throughput for the components in the I/O path, the paths are set up correctly.
Note: Because the test could cause significant performance issues, exercise caution if the test is run on a production system.
To help define I/O requirements, Dell Technologies recommends using Dell Live Optics on a simulated production system during at least a 24-hour period that includes the peak workload. If it is not possible to simulate the production system, using an I/O testing tool to simulate the production system might be possible. For a sample of available testing tools, see the following table:
Category | Tool | Vendor |
I/O subsystem | Dell Live Optics (formally DPACK) | Dell Technologies |
Oracle | ||
Iometer Org | ||
SourceForge | ||
Free Software Foundation | ||
Linux operating system | ||
RDBMS | Kevin Closson | |
Oracle PL/SQL package DBMS_RESOURCE_MANAGER.CALIBRATE_IO | Oracle | |
Transactional | Quest | |
Open Source | ||
Dominicgiles | ||
Oracle |
The performance analysis tools can:
If it is not possible to run Dell Live Optics or another testing tool, test the paths between the server and PowerStore. The tests should perform large block sequential reads using small files (one file per volume, per PowerStore node). Tests should use multiple threads and use 512 KB blocks and a queue depth of 32 to saturate all paths. A successful test verifies that all paths are functioning and will yield the I/O potential of the array. If the throughput matches the expected throughput for the number of server HBA ports, the I/O paths between the PowerStore array and the server are configured correctly. If the test is run on a PowerStore array not dedicated to this test, it could cause significant performance issues. If smaller blocks are used for the test, I/O saturation rates might not be achievable. Small block tests might not verify that all paths are functioning and will yield the I/O potential of the array.
Repeat this test and validate the process on the production server after go-live to validate and establish a benchmark of initial performance metrics.
Once a design can deliver the expected throughput requirement, more disks can be added to the storage solution to meet capacity requirements. However, the converse is not necessarily true. If a design meets the expected capacity requirements, adding disks to the storage solution might not make the design meet the required throughput requirements. For example, because disk drive capacity is growing faster than disk I/O throughput rates, a situation can occur where fewer disks can store a large volume of data. A smaller number of large disks cannot provide the same I/O throughput as a larger number of smaller disks.
After validating the throughput of I/O paths between the PowerStore array and the server, and meeting capacity requirements, test the disk I/O capabilities for the designed workload. Successful tests validate that the storage design provides the required IOPS and throughput with acceptable latencies. The test must not exceed the designed capacity of the array, otherwise the test results will be misleading. If the test does exceed the designed capacity, reduce the number of test threads, outstanding I/Os, or both. Testing random I/O should be done with I/O sizes of 8 KB and 16 KB as a starting point and adjust from there. When testing sequential I/O, I/O sizes should be 8 KB, 16 KB, 64 KB, or larger.
This testing methodology assumes the guidelines mentioned in previous sections have been followed and modified according to business requirements.
The principle of stripe-far-and-wide needs to be used in tandem with data warehouses to increase the throughput potential of the I/O paths.