Skip site navigation (1) Skip section navigation (2)

Re: Initial 9.2 pgbench write results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Initial 9.2 pgbench write results
Date: 2012-02-28 18:10:53
Message-ID: 8285.1330452653@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> How hard would it be to dummy up a bgwriter which, every time it wakes
> up, it forks off a child process to actually do the write, and then
> the real one just waits for the child to exit?  If it didn't have to
> correctly handle signals, SINVAL, and such, it should be just a few
> lines of code, but I don't know how much we can ignore signals and
> such even just for testing purposes.  My thought here is that the
> kernel is getting in a snit over one process doing all the writing on
> the system, and is punishing that process in a way that ruins things
> for everyone.

If that is the case (which I don't know one way or the other), I'm not
sure that having subprocesses do the work would be an improvement.
We know for a fact that the OOM killer knows enough to blame memory
consumed by a child process on the parent.  Resource limitations of
other sorts might work similarly.

But a bigger problem is that fork() is very very far from being zero
cost.  I think doing one per write() would swamp any improvement you
could hope to get.

It does make sense that the bgwriter would get hit by niceness penalties
after it'd run up sufficient runtime.  If we could get some hard numbers
about how long it takes for that to happen, we could consider letting
the bgwriter exit (and the postmaster spawn a new one) every so often.
This is just gaming the scheduler, and so one would like to think
there's a better way to do it, but I don't know of any
non-root-privilege way to stave off getting niced.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-02-28 18:11:38
Subject: Re: CLOG contention, part 2
Previous:From: Robert HaasDate: 2012-02-28 17:49:06
Subject: Re: Initial 9.2 pgbench write results

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group