There is no single simple test that will tell if the disk performance is acceptable as there are many variables that may impact the DB performance.
However, nn widely accepted method by Progress DBAs and consultants alike is the "Furgal Test".
It is another use-case for the BIGROW command, used to measure disk speed specifically by timing how long it takes to grow a bi file of a certain size on disk.
This benchmark provides a quick and easy means to uniformly gather information about synchronous I/O performance. The results enable:
- Comparative BIGROW performance results with other environments when investigating bottlenecks on I/O or CPU that are impacting our ability to write changes to disk in a timely fashion. For example when Checkpoint metrics show Sync Time as a fair proportion of the Checkpoint Duration timings.
- A litmus test of sorts. While bigrow is sequential and database I/O is completely random, experience has shown a strong correlation between long bigrow times and poor application/database performance.
- To keep an eye on infrastructure trends that influence OpenEdge performance. This (historic or environment comparative) evidence provides a reliable indicator of storage implementation and/or configuration issues which lead back to database/application performance problems.
In order to execute this unbuffered I/O test use the undocumented parameter: -zextendSyncIO.
This parameter is not ever expected to be needed otherwise unless bigrow is being used as a benchmark on platforms running an OpenEdge version with disk I/O performance improvements.Example:
Re-format 96 MB disk space to pre-allocate 6 bi clusters
A BIGROW benchmark widely accepted over the years and across many different storage systems is that it should take no longer than 10 seconds to write a 100 MB BI file.
To verify a minimum of 10 MB/Second sequential write speed measured using a BIGROW benchmark
Add the 4 default bi clusters to the bi grow value specified, to pre-grow the required number of bi clusters
UNIX: 16 MB bi cluster size with 1024 16 KB bi blocks
proutil <dbname> -C truncate bi -bi 16384 -biblocksize 16
time -p proutil <dbname> -C bigrow 2 -zextendSyncIO
Windows: 16 MB bi cluster size with 2048 8 KB bi blocks
proutil <dbname> -C truncate bi -bi 16384 -biblocksize 8
timer.bat "proutil <dbname> -C bigrow 2 -zextendSyncIO
REM: timer.bat to fake UNIX 'time'
echo %time% < nul
cmd /c %1
echo %time% < nul
When sequential write speed is not optimal and other OS metrics refute results, other tools outside of Progress will provide supporting evidence.
One use-case example is recorded in Article The "proutil bigrow"command performs differently between 2 different disks types