Re: postgresql latency & bgwriter not doing its job

From: Mitsumasa KONDO <kondo(dot)mitsumasa(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgresql latency & bgwriter not doing its job
Date: 2014-08-31 02:02:48
Message-ID: CADupcHXqXATH6y-BZUu6qGqkfPgbrPi_5mAQ0+8XFoCuMvG=LA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

2014-08-31 8:10 GMT+09:00 Andres Freund <andres(at)2ndquadrant(dot)com>:

> On 2014-08-31 01:50:48 +0300, Heikki Linnakangas wrote:
>
> If we're going to fsync between each file, there's no need to sort all the
> > buffers at once. It's enough to pick one file as the target - like in my
> > crude patch - and sort only the buffers for that file. Then fsync that
> file
> > and move on to the next file. That requires scanning the buffers multiple
> > times, but I think that's OK.
>
> I really can't see that working out. Production instances of postgres
> with large shared_buffers settings (say 96GB in one case) have tens of
> thousands of relations (~34500 in the same case). And that's a database
> with a relatively simple schema. I've seen much worse.

Yeah, it is impossible in one checkpointer process. All buffer search cost
is
relatively high than we expect. We need clever algorithm for efficient and
distributed buffer search using multi process or threads.

Regards,
--
Mitsumasa KONDO

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-08-31 02:59:07 Re: PATCH: Allow distdir to be overridden on make command line
Previous Message Peter Eisentraut 2014-08-31 01:37:28 Re: PATCH: Allow distdir to be overridden on make command line