> Then the > database makes the fsync call, and suddenly the OS wants to flush 2-6GB of > data > straight to disk. Without that background trickle, you now have a flood that > only the highest-end disk controller or a backing-store full of SSDs or PCIe > NVRAM could ever hope to absorb.
Isn't checkpoint_completion_target supposed to deal exactly with that problem? Plus: if 2-6GB is too much, why not decrease checkpoint_segments? Or checkpoint_timeout? > The kernel > developers agree, or we wouldn't have dirty_bytes, or > dirty_background_bytes, and they wouldn't have changed the defaults to 5% > and 10% instead of 10% and 40%. I'm not saying that those kernel parameters are "useless"; I'm saying they are used in the same way as the checkpoint_segments, checkpoint_timeout and checkpoint_completion_target are used by postgresql; and on a postgresql-only system I would rather have postgresql look after the fsync calls, not the OS. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
