This section presents information for tuning hashed shared disk performance.
Since, all I/O requests are passed to the underlying virtual shared disks, the parameters you select when configuring virtual shared disks affect the performance of hashed shared disks. Therefore, hashed shared disk tuning is discussed in relationship to these additional performance considerations:
The parameters that can be tuned to affect performance are:
To take advantage of the parallelism potential, the stripe size should be smaller than the application's request size.
Request latency for a hashed shared disk or virtual shared disk is primarily gated by disk I/O. Disk I/O can be separated into three distinct operations:
The smaller the stripe size, the smaller the transfer delay. Hashed Shared Disk data striping allows the system to handle virtual shared disk requests in parallel.
If your system is CPU bound, using the Hashed Shared Disk subsystem (with a stripe size greater than the buddy buffer size) can help only with eliminating I/O bottlenecks. Eliminating I/O bottlenecks might improve overall transaction throughput. You should consider spreading the workload by adding more nodes or disks.
If your system is I/O bound, using the Hashed Shared Disk subsystem might help. However, consider that:
The only way to fully optimize a hashed shared disk to your environment is to try out different configurations. The main obstacle in tuning a hashed shared disk is that it is not simple to add or remove virtual shared disks and change the stripe size after the hashed shared disk is loaded with data. The only way to do this is to back up the hashed shared disk (using dd), recreate it, and load it with the new parameters. Therefore, give careful consideration to planning how you will use a hashed shared disk. If tuned properly, a hashed shared disk can significantly improve virtual shared disk throughput performance.