At the time a bi checkpoint is triggered, the bi mechanism must flush all modified database blocks found in the full bi cluster and place them onto the checkpoint queue.
After the checkpoint it will issue a UNIX SYNC to tell the operating system to flush all modified O/S blocks from the UNIX cache. This includes all database pages present in the filesystem cache as well as other pages that have nothing to do with the database. Any process writing must wait until the filesystem write operations have completed.
With very active databases often with large bi cluster sizes, this task can take a fair amount of time and could become quite noticeable to the clients.
0. Tune BI I/O Performance and Upgrade for Product BI Performance enhancements:
In OpenEdge 11.7.6 and 11.2.1, all supported platforms were enhanced to use this new mechanism:
1. Use the database startup parameter -directio to spread the I/O load.
2. Start more APW'sWith or without -directio, enabling more APW's will flush buffers, so there are less buffers to flush at checkpoint time. Assure that a BIW is started and an AIW (if after-imaging is enabled)
3. Tune the UNIX sync commandProgress 9.1E02 and OpenEdge 10.0B02 Service packs, code was introduced to use
fdatasync rather than
sync which ensures the data associated with closed bi clusters is flushed to disk before returning. There is no longer any need to wait a specific amount of time anymore as previously with the sync call. The -G parameter which used to default to 60 seconds was changed to 0 seconds because of this change.
The UNIX
sync command usually runs every 30/60 seconds but may need to run more often to spread the I/O load. More frequent flushes of the file system caches means that the sync() calls issued by the storage manager therefore take less time. Consult with your Operating System vendor on how to do this. One possibility is to have a shell script running in the background, which does something similar to this:
while:
do
sleep 5
sync
Done
