From: Leonardo Francalanci <m_lists@yahoo.it>
To: sthomas@peak6.com <sthomas@peak6.com>
Cc: alexandre - aldeia digital <adaldeia@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Adding more memory = hugh cpu load
Date: Mon, 10 Oct 2011 17:14:37 +0100 (BST)
Message-ID: <1318263277.56967.YahooMailNeo@web29013.mail.ird.yahoo.com> (raw)
In-Reply-To: <4E93119C.8090407@peak6.com>
References: <4E92F294.9010405@gmail.com>
<4E92FB87.1030703@peak6.com>
<1318259675.10344.YahooMailNeo@web29011.mail.ird.yahoo.com>
<4E93119C.8090407@peak6.com>
> 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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: m_lists@yahoo.it, sthomas@peak6.com, adaldeia@gmail.com
Subject: Re: Adding more memory = hugh cpu load
In-Reply-To: <1318263277.56967.YahooMailNeo@web29013.mail.ird.yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox