Here is an attempt to explain how the group delay option works. By Gus Bjorklund
Group Delay Option
- Thread starter Chris Kelleher
- Start date
Here is an attempt to explain how the group delay option works.
A transaction is not durable until the transaction commit record has been
written to disk in the undo/redo (aka before-image) log. Until it is safely
on disk, a crash could cause it to be lost, resulting in an incomplete
transaction that will be either:
backed out during crash recovery if it is not a 2pc transaction, or
it will become a "limbo" transaction such that the database does not
know if it was committed or not.
The obvious method for ensuring that the commit is durable is to always
force the current bi log buffer to disk immediately after a commit record is
spooled to it before allowing the application to continue. This is not
optimal because it requires a synchronous write to disk for every commit,
limiting total throughput to however many writes per second one can do the
bi disk.
Another method is to allow the application to continue after it has issued a
commit and then writing the bi buffer to disk a short time afterward. This
introduces a small window where the application thinks the transaction has
been committed but it may later be lost and rolled back. It is 'cheating'
but in practice rarely causes a problem. In a system with a lot of activity,
the window is pretty small because the current bi buffer will fill and be
written to disk in a few milliseconds. If there isn't a lot of activity, the
commit record could sit in memory for awhile. Progress has a "fuzzy commit"
option, controlled by the -Mf startup parameter, that puts an upper bound on
this. After -Mf seconds a bi buffer that contains a commit record will be
written to disk even if it is not full. If you are going to use it, set it
to 1. Bigger numbers don't have any benefit and one extra bi write now and
then does not have a noticeable effect.
The group delay mechanism offers another solution. It is a *compromise* that
introduces a short delay for an individual transaction for the benefit of
all. When there are multiple users generating activity on the database
instead of cheating with fuzzy commit or making every transaction always for
a write, we delay the committing transaction a few milliseconds before
allowing it to continue. During the delay, one of the following will happen:
- the bi log buffer will fill and be written to disk. The process continues
and everything is fine. We have saved an extra write.
- another transaction (or perhaps several) will also generate a commit
record but not fill the buffer. They will all delay. When the delay expires,
the bi buffer is written disk, committing multiple transactions in one i/o
operation. All the waiting processes continue.
- there are no more bi log records generated, perhaps because there is only
one active transaction. In this case, the delay expires and the bi buffer is
written. The delayed transaction continues.
As you can see, the group delay timer is not a "gas pedal". With only one
user, the delay just makes that one transaction take longer. With multiple
users, you want to make the delay just long enough to piggyback regular
activity on the commit. The longer you set it, the longer one has to wait if
the buffer doesn't fill fast enough.
So therefore you shouldn't set it very high. I would guess 25 ms would be
close to right. But ymmv.-- regards,gus
****************************************************************
Gus Bjorklund, Progress Software Corporation, Bedford MA.
Purveyors of the finest rdbms on the third planet from the sun.
A transaction is not durable until the transaction commit record has been
written to disk in the undo/redo (aka before-image) log. Until it is safely
on disk, a crash could cause it to be lost, resulting in an incomplete
transaction that will be either:
backed out during crash recovery if it is not a 2pc transaction, or
it will become a "limbo" transaction such that the database does not
know if it was committed or not.
The obvious method for ensuring that the commit is durable is to always
force the current bi log buffer to disk immediately after a commit record is
spooled to it before allowing the application to continue. This is not
optimal because it requires a synchronous write to disk for every commit,
limiting total throughput to however many writes per second one can do the
bi disk.
Another method is to allow the application to continue after it has issued a
commit and then writing the bi buffer to disk a short time afterward. This
introduces a small window where the application thinks the transaction has
been committed but it may later be lost and rolled back. It is 'cheating'
but in practice rarely causes a problem. In a system with a lot of activity,
the window is pretty small because the current bi buffer will fill and be
written to disk in a few milliseconds. If there isn't a lot of activity, the
commit record could sit in memory for awhile. Progress has a "fuzzy commit"
option, controlled by the -Mf startup parameter, that puts an upper bound on
this. After -Mf seconds a bi buffer that contains a commit record will be
written to disk even if it is not full. If you are going to use it, set it
to 1. Bigger numbers don't have any benefit and one extra bi write now and
then does not have a noticeable effect.
The group delay mechanism offers another solution. It is a *compromise* that
introduces a short delay for an individual transaction for the benefit of
all. When there are multiple users generating activity on the database
instead of cheating with fuzzy commit or making every transaction always for
a write, we delay the committing transaction a few milliseconds before
allowing it to continue. During the delay, one of the following will happen:
- the bi log buffer will fill and be written to disk. The process continues
and everything is fine. We have saved an extra write.
- another transaction (or perhaps several) will also generate a commit
record but not fill the buffer. They will all delay. When the delay expires,
the bi buffer is written disk, committing multiple transactions in one i/o
operation. All the waiting processes continue.
- there are no more bi log records generated, perhaps because there is only
one active transaction. In this case, the delay expires and the bi buffer is
written. The delayed transaction continues.
As you can see, the group delay timer is not a "gas pedal". With only one
user, the delay just makes that one transaction take longer. With multiple
users, you want to make the delay just long enough to piggyback regular
activity on the commit. The longer you set it, the longer one has to wait if
the buffer doesn't fill fast enough.
So therefore you shouldn't set it very high. I would guess 25 ms would be
close to right. But ymmv.-- regards,gus
****************************************************************
Gus Bjorklund, Progress Software Corporation, Bedford MA.
Purveyors of the finest rdbms on the third planet from the sun.
