Postgres memory tuning is a budget problem. shared_buffers, OS cache, work_mem, maintenance work, and connection count all spend the same RAM.
Database Topic Archive
CPU, Memory, and I/O Articles
CPU, memory, disk, temp files, checkpoints, buffers, and workload pressure.
Disk-full on a Postgres server is rarely just one thing. WAL, temp files, logs, and delayed cleanup arrive together. The recovery is mostly about what you prepared before.
Checkpoint problems show up as periodic latency spikes. The work is smoothing writes, sizing WAL, and proving checkpoints are the thing users feel.
When Postgres CPU is high, the question is not whether the server is fast enough. It is which queries are using the cycles and whether they should be.
High I/O is not a storage verdict. It is a workload question: which query, table, index, vacuum, checkpoint, or spill is reading and writing the bytes?
A Postgres OOM kill is one of the few crashes that is almost always preventable. The pattern is consistent enough to have a checklist.
Temp files are hidden disk work. They explain slow sorts, hash joins, and aggregations that look fine until work_mem runs out under real concurrency.