|
571 | 571 | writing dirty buffers during a checkpoint is spread over a period of time.
|
572 | 572 | That period is controlled by
|
573 | 573 | <xref linkend="guc-checkpoint-completion-target"/>, which is
|
574 |
| - given as a fraction of the checkpoint interval. |
| 574 | + given as a fraction of the checkpoint interval (configured by using |
| 575 | + <varname>checkpoint_timeout</varname>). |
575 | 576 | The I/O rate is adjusted so that the checkpoint finishes when the
|
576 | 577 | given fraction of
|
577 | 578 | <varname>checkpoint_timeout</varname> seconds have elapsed, or before
|
578 | 579 | <varname>max_wal_size</varname> is exceeded, whichever is sooner.
|
579 |
| - With the default value of 0.5, |
| 580 | + With the default value of 0.9, |
580 | 581 | <productname>PostgreSQL</productname> can be expected to complete each checkpoint
|
581 |
| - in about half the time before the next checkpoint starts. On a system |
582 |
| - that's very close to maximum I/O throughput during normal operation, |
583 |
| - you might want to increase <varname>checkpoint_completion_target</varname> |
584 |
| - to reduce the I/O load from checkpoints. The disadvantage of this is that |
585 |
| - prolonging checkpoints affects recovery time, because more WAL segments |
586 |
| - will need to be kept around for possible use in recovery. Although |
587 |
| - <varname>checkpoint_completion_target</varname> can be set as high as 1.0, |
588 |
| - it is best to keep it less than that (perhaps 0.9 at most) since |
589 |
| - checkpoints include some other activities besides writing dirty buffers. |
| 582 | + a bit before the next scheduled checkpoint (at around 90% of the last checkpoint's |
| 583 | + duration). This spreads out the I/O as much as possible so that the checkpoint |
| 584 | + I/O load is consistent throughout the checkpoint interval. The disadvantage of |
| 585 | + this is that prolonging checkpoints affects recovery time, because more WAL |
| 586 | + segments will need to be kept around for possible use in recovery. A user |
| 587 | + concerned about the amount of time required to recover might wish to reduce |
| 588 | + <varname>checkpoint_timeout</varname> so that checkpoints occur more frequently |
| 589 | + but still spread the I/O across the checkpoint interval. Alternatively, |
| 590 | + <varname>checkpoint_completion_target</varname> could be reduced, but this would |
| 591 | + result in times of more intense I/O (during the checkpoint) and times of less I/O |
| 592 | + (after the checkpoint completed but before the next scheduled checkpoint) and |
| 593 | + therefore is not recommended. |
| 594 | + Although <varname>checkpoint_completion_target</varname> could be set as high as |
| 595 | + 1.0, it is typically recommended to set it to no higher than 0.9 (the default) |
| 596 | + since checkpoints include some other activities besides writing dirty buffers. |
590 | 597 | A setting of 1.0 is quite likely to result in checkpoints not being
|
591 | 598 | completed on time, which would result in performance loss due to
|
592 | 599 | unexpected variation in the number of WAL segments needed.
|
|
0 commit comments