Did this article resolve your question/issue?



Is there a simple test to validate if disk speed is acceptable in relation to database I/O operations?

« Go Back


TitleIs there a simple test to validate if disk speed is acceptable in relation to database I/O operations?
URL NameIs-there-a-simple-test-to-validate-if-disk-speed-is-acceptable-in-relation-to-database-I-O-operations
Article Number000151391
EnvironmentProduct: OpenEdge
Version: All supported versions
OS: All supported platforms
Question/Problem Description
Is there a simple test to validate if disk speed is acceptable in relation to database I/O operations?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
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.


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 off
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
This tests before-image log write performance.
it correlates well with performance (i.e. poor result is a predictor of poor performance) but it isn't the whole story.
Just as important is random read/write speed for data extents.
Whether disk bandwidth is sufficient is highly dependent on the application, the number of users, database configuration parameter settings, kernel settings, the overall workload, and other factors.
There is no simple "rule-of-thumb" that will suit everyone.
Last Modified Date11/20/2020 6:56 AM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.