| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dave Chinner <david(at)fromorbit(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Mel Gorman <mgorman(at)suse(dot)de>, Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Joshua Drake <jd(at)commandprompt(dot)com>, "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-16 00:38:35 |
| Message-ID: | 6600.1389832715@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I don't see that as a problem. What we're struggling with today is
> that, until we fsync(), the system is too lazy about writing back
> dirty pages. And then when we fsync(), it becomes very aggressive and
> system-wide throughput goes into the tank. What we're aiming to do
> here is get is to start the writeback sooner than it would otherwise
> start so that it is spread out over a longer period of time.
Yeah. It's sounding more and more like the right semantics are to
give the kernel a hint that we're going to fsync these files later,
so it ought to get on with writing them anytime the disk has nothing
better to do. I'm not sure if there's value in being specific about
how much later; that would probably depend on details of the scheduler
that I don't know.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Chinner | 2014-01-16 00:47:17 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
| Previous Message | Tom Lane | 2014-01-16 00:31:15 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |