| From: | Leonardo Francalanci <m_lists(at)yahoo(dot)it> |
|---|---|
| To: | "sthomas(at)peak6(dot)com" <sthomas(at)peak6(dot)com> |
| Cc: | alexandre - aldeia digital <adaldeia(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Adding more memory = hugh cpu load |
| Date: | 2011-10-10 16:14:37 |
| Message-ID: | 1318263277.56967.YahooMailNeo@web29013.mail.ird.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | alexandre - aldeia digital | 2011-10-10 17:31:40 | Re: Adding more memory = hugh cpu load |
| Previous Message | Greg Smith | 2011-10-10 16:07:34 | Re: Adding more memory = hugh cpu load |