Checkpoint Amplification
partialModeratecapacity failure · linear propagation
Blast Radius
46%
5/11 nodes
Time to Detect
Detectable within minutes with pg_stat_bgwriter monitoring and I/O utilisation trending. The periodic pattern (spikes at exactly checkpoint_timeout intervals) is the distinguishing characteristic: it is not random latency, it is clock-driven. Without checkpoint-specific monitoring, the pattern may be attributed to generic I/O variability for weeks before the periodicity is noticed.
Preventive Mitigations
0
Confidence
StrongImpacted Components
Write-Heavy Transactional
workload · Directly connected to failure mode 'Checkpoint Amplification' via risk propagation path in the topology.
Transactional Outbox Pattern
architecture pattern · Connected to directly impacted component(s): Write-Heavy Transactional.
Checkpoint Amplification
operational risk · Connected to directly impacted component(s): Write-Heavy Transactional.
Lock Contention
operational risk · Connected to directly impacted component(s): Write-Heavy Transactional.
WAL Saturation
operational risk · Connected to directly impacted component(s): Write-Heavy Transactional.
Failure Cascade
Write-Heavy Transactional
Checkpoint Amplification (linear propagation) directly affects these components.
Severity at this step: partial
Checkpoint Amplification, Lock Contention, Transactional Outbox Pattern, WAL Saturation
Failure propagates through dependency edges to connected components. Degradation manifests as latency spikes, error rate increases, or reduced throughput on dependent services.
Severity at this step: partial
Detection Signals
Recovery time estimate: Tuning changes (checkpoint_completion_target, checkpoint_timeout) take effect within minutes without a database restart. I/O pattern improvement is visible within the next 1–2 checkpoint cycles (5–30 minutes). No service interruption required for these configuration changes.
Mitigation Checklist(0 preventive, 4 reactive)
Smaller shared_buffers means fewer dirty pages to flush per checkpoint. Counter-intuitive: reducing shared_buffers from 16GB to 8GB on a write- heavy workload can reduce checkpoint I/O amplitude at the cost of slightly reduced cache hit rate. Measure cache hit rate before and after.
On Linux, enable HugeTLB (2MB pages) for shared_buffers by setting huge_pages = on in postgresql.conf and allocating sufficient hugepages at the OS level. Reduces checkpoint overhead from TLB invalidations during page dirty-tracking, which is a CPU cost that compounds with large shared_buffers.
ALTER SYSTEM SET checkpoint_completion_target = 0.9; SELECT pg_reload_conf(). On PostgreSQL 14 and later this is already the default, so check pg_settings before assuming action is needed; the setting only needs changing if it was manually lowered. On PostgreSQL 13 and earlier, this is a required change: the shipped default is 0.5. Either way, 0.9 spreads checkpoint writes over 90% of the checkpoint interval instead of 50%, reducing peak I/O spike at checkpoint time. Takes effect immediately without restart. Does not reduce total checkpoint I/O volume; spreads the same work more evenly.
Set checkpoint_timeout = '15min' or '30min'. Fewer checkpoints per hour means fewer I/O bursts. However: longer checkpoint intervals increase WAL retained for crash recovery (max_wal_size may also need increasing) and extend crash recovery time. Trade-off: more time between checkpoints increases recovery time after a crash.
Affected Systems
Workloads
Blast radius analysis is derived from structured topology and failure mode knowledge. It models structural propagation patterns, not measured production behavior. Actual incident scope depends on runtime conditions, traffic, and recovery actions in place at the time of failure.