From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "James Pang (chaolpan)" <chaolpan(at)cisco(dot)com> |
Cc: | "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: any impact to DML sql statements when checkpoint starting |
Date: | 2022-02-04 00:50:14 |
Message-ID: | CAKFQuwad6xiKpVs0NiSHMD71eivTUXRchJFhOH0ZHrfM36M2yg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, Feb 3, 2022 at 5:45 PM James Pang (chaolpan) <chaolpan(at)cisco(dot)com>
wrote:
> So the main concern about checkpoint impact is IO, in order to reduce
> the IO by checkpoint, in addition to postgres checkpoint parameters.
> Linux(Redhat 8), some OS kernel parameters need to be set ,right?
>
>
>
> vm.dirty_expire_centisecs=500
>
> vm.dirty_writeback_centisecs=250
>
> vm.dirty_ratio=30
>
> vm.dirty_background_ratio = 10
>
>
>
I understand the big picture (more-or-less), not tuning specifics. But for
a checkpoint we don't really give the O/S much control - it needs to do
fsync when we ask for it. It's in between the explicit issuance of
checkpoints that the algorithms written into PostgreSQL and the O/S come
into play to hopefully spread out the load over more time and keep the
active memory holding useful data.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | James Pang (chaolpan) | 2022-02-04 00:55:31 | RE: any impact to DML sql statements when checkpoint starting |
Previous Message | James Pang (chaolpan) | 2022-02-04 00:45:44 | RE: any impact to DML sql statements when checkpoint starting |