From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jan Kara <jack(at)suse(dot)cz> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Dave Chinner <david(at)fromorbit(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Trond Myklebust <trondmy(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Joshua Drake <jd(at)commandprompt(dot)com>, James Bottomley <James(dot)Bottomley(at)hansenpartnership(dot)com>, Mel Gorman <mgorman(at)suse(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "lsf-pc(at)lists(dot)linux-foundation(dot)org" <lsf-pc(at)lists(dot)linux-foundation(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Date: | 2014-01-14 19:07:47 |
Message-ID: | CA+TgmoZkKjLGr3o72H3dyw-gmRze6LLkKzNO+8u+QuRqHSV1rw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 14, 2014 at 1:37 PM, Jan Kara <jack(at)suse(dot)cz> wrote:
> Just to get some idea about the sizes - how large are the checkpoints we
> are talking about that cause IO stalls?
Big. Potentially, we might have dirtied all of shared_buffers and
then started evicting pages from there to the OS buffer pool and
dirties as much memory as the OS will allow, and then the OS might
have started writeback and filled up all the downstream caches between
the OS and the disk. And then just then the checkpoint hits.
I dunno what a typical checkpoint size is but I don't think you'll be
exaggerating much if you imagine that everything that could possibly
be dirty is.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-01-14 19:09:48 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Previous Message | Heikki Linnakangas | 2014-01-14 19:07:30 | Re: GIN improvements part2: fast scan |