Re: Adding more memory = hugh cpu load
От | Leonardo Francalanci |
---|---|
Тема | Re: Adding more memory = hugh cpu load |
Дата | |
Msg-id | 1318263277.56967.YahooMailNeo@web29013.mail.ird.yahoo.com обсуждение исходный текст |
Ответ на | Re: Adding more memory = hugh cpu load (Shaun Thomas <sthomas@peak6.com>) |
Ответы |
Re: Adding more memory = hugh cpu load
|
Список | 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.
В списке pgsql-performance по дате отправления: