From 277fac2f2866daa15d12f4e2cc72f51cafb1b64c Mon Sep 17 00:00:00 2001 From: Radko Krkos Date: Wed, 16 Jan 2019 18:25:37 +0100 Subject: [PATCH] Updated database documentation - AUTOVACUUM tuning --- doc/sphinx/_doclib/database.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/sphinx/_doclib/database.rst b/doc/sphinx/_doclib/database.rst index 5114055..8dbd93e 100644 --- a/doc/sphinx/_doclib/database.rst +++ b/doc/sphinx/_doclib/database.rst @@ -129,9 +129,9 @@ As of PostgreSQL 9.6, with significant further improvements in 10.0, individual .. code-block:: shell # Original default value 1 - effective_io_concurrency = 8 + effective_io_concurrency = 4 -* Defines the optimal number of parallel IO requests for the disk subsystem. Default value of 1 is aimed at HDDs, SSDs perform best with values of 4 - 8, NVMe SSDs can support much higher values. Chosen value of 8 seems representative of example server's storage capabilities. +* Defines the optimal number of parallel IO requests for the disk subsystem. Default value of 1 is aimed at non-RAID HDDs; SATA SSDs perform best with values of 4 - 8; NVMe SSDs can support much higher values. Chosen value of 4 seems representative of example server's storage capabilities. .. code-block:: shell @@ -204,12 +204,12 @@ Regular VACUUM and ANALYZE .. code-block:: sql # Original default value -1 (use vacuum_cost_limit) - autovacuum_vacuum_cost_limit = 10000 + autovacuum_vacuum_cost_limit = 5000 # Original default value 20ms - autovacuum_vacuum_delay = 0ms + autovacuum_vacuum_delay = 10ms -* These settings limit the automatic ``VACUUM`` operation, when the cost limit is reached (same scale as other costs), the operation is postponed for the length of delay. Default values of cost 200 and delay 20 ms are aimed at very low additional load to be generated by this background task to affect normal operation. As this is mostly CPU bound and runs in single thread, we can allow for more aggressive values in our use case. For large tables such as events, this allows the autovacuum to finish in a few seconds instead of tens of minutes with default values. The risk of cancelling background ``VACUUM`` due to conflicting operation is therefore minimized and the reclamation of invalidated rows is performed much more promptly what reduces index bloat considerably. +* These settings limit the automatic ``VACUUM`` operation, when the cost limit is reached (same scale as other costs), the operation is postponed for the length of delay. Default values of cost 200 and delay 20 ms are aimed at very low additional load to be generated by this background task to affect normal operation. As this is mostly CPU bound and runs in single thread, we can allow for more aggressive values in our use case. For large tables such as events, this allows the autovacuum to finish in a few minutes instead of tens of minutes with default values. The risk of cancelling background ``VACUUM`` due to conflicting operation is therefore lowered and the reclamation of invalidated rows is performed much more promptly what reduces the index and table bloat considerably. The chosen value of delay still enables brief autovacuum process sleeps during the run, what is aimed at preventing disk subsystem overload as ``VACUUM`` tends to be an IO heavy operation. Current database schema -- 2.10.0.windows.1