Kbase 19295: Groupdelay explanation
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/12/1999 |
|
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.
Further details may be found in kbase 18003.