On Jun 13, 2006, at 9:42 PM, Kris Kennaway wrote:
BTW, there's another FBSD performance odditiy I've run across.
Running
pg_dump -t email_contrib -COx stats | bzip2 > ec.sql.bz2 &
which dumps the email_contrib table to bzip2 then to disk, the OS
won't use more than 1 CPU on an SMP system... u
Moving to osdldbt-general and dropping Tom and Marc.
On Jun 13, 2006, at 1:18 PM, Kris Kennaway wrote:
On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
Unless supersmack has improved substantially, you're unlikely to find
much interest. Last I heard it was a pretty brain-dead benc
On Fri, Jun 16, 2006 at 07:56:30AM -0400, Rod Taylor wrote:
> > > I did have dbt2 pretty close to functional on FreeBSD a year ago but
> > > it's probably gone back into linuxisms since then.
> >
> > :(
> >
> > I won't have the chance to work on this further for another 2 months,
> > but if you h
On Thu, Jun 15, 2006 at 11:34:52PM -0400, Rod Taylor wrote:
> On Tue, 2006-06-13 at 14:18 -0400, Kris Kennaway wrote:
> > On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
> >
> > > Unless supersmack has improved substantially, you're unlikely to find
> > > much interest. Last I heard
> > I did have dbt2 pretty close to functional on FreeBSD a year ago but
> > it's probably gone back into linuxisms since then.
>
> :(
>
> I won't have the chance to work on this further for another 2 months,
> but if you have patches I could see about picking up on them when I
> get back.
Every
On Tue, 2006-06-13 at 14:18 -0400, Kris Kennaway wrote:
> On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
>
> > Unless supersmack has improved substantially, you're unlikely to find
> > much interest. Last I heard it was a pretty brain-dead benchmark. DBT2/3
> > (http://sourceforge.n
On Tue, Jun 13, 2006 at 03:55:38PM -0500, Jim Nasby wrote:
>
> On Jun 12, 2006, at 10:38 AM, Kris Kennaway wrote:
> >>>FYI, the biggest source of contention is via semop() - it might be
> >>>possible to optimize that some more in FreeBSD, I don't know.
> >>
> >>Yeah, I've seen PostgreSQL on FreeBS
On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
> Unless supersmack has improved substantially, you're unlikely to find
> much interest. Last I heard it was a pretty brain-dead benchmark. DBT2/3
> (http://sourceforge.net/projects/osdldbt) is much more realistic (based
> on TPC-C and
On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
> > > Can you provide the actual commands you used to setup and run the test?
> >
> > I actually forget all the steps I needed to do to get super-smack
> > working with postgresql since it required a lot of trial and error for
> > a da
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Even if what's being written is a single byte/word and we're taking
> intentional steps to make sure that reading a pointer that's off by 1
> isn't an issue? Is the issue that if CPU A writes a pointer and CPU B
> immediately tries to read it that it c
Greg Stark <[EMAIL PROTECTED]> writes:
> Well if all we want to do is reproduce the current functionality of EXPLAIN
> ANALYZE, all you need is a single sig_atomic_t int that you store the address
> of the current node in.
Do I need to point out that sig_atomic_t can't portably be assumed to be
wi
On Wed, Jun 14, 2006 at 10:37:59PM +0200, Martijn van Oosterhout wrote:
> On Wed, Jun 14, 2006 at 03:21:55PM -0500, Jim C. Nasby wrote:
> > One idea would be to keep something akin to a FIFO, where the backend
> > would write records instead of updating/over-writing them, and the
> > reader process
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The numbers I've been looking at lately say that heavy lock traffic is
> > expensive, particularly on SMP machines, even with zero contention.
> > Seems the cache coherency protocol costs a lot even when it's not doing
> > anything...
>
> Are there
On Wed, Jun 14, 2006 at 03:21:55PM -0500, Jim C. Nasby wrote:
> One idea would be to keep something akin to a FIFO, where the backend
> would write records instead of updating/over-writing them, and the
> reader process would only read records where there was no risk that they
> were still being wr
On Wed, Jun 14, 2006 at 03:51:28PM -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> This sounds good until you think about locking. It'd be quite
> >> impractical to implement anything as fine-grained as EXPLAIN ANALYZE
> >> this way, be
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> This sounds good until you think about locking. It'd be quite
>> impractical to implement anything as fine-grained as EXPLAIN ANALYZE
>> this way, because of the overhead involved in taking and releasing
>> spinlocks.
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > If backends store their current status in shared memory then a separate
> > process entirely can receive the interrupts, scan through the shared memory
> > process states and do the accounting.
>
> This sounds good
Greg Stark <[EMAIL PROTECTED]> writes:
> If backends store their current status in shared memory then a separate
> process entirely can receive the interrupts, scan through the shared memory
> process states and do the accounting.
This sounds good until you think about locking. It'd be quite
impr
Martijn van Oosterhout writes:
> With one big exception: sometimes I/O is non-interruptable (the good
> old D state). In this case the interrupts will happen but will simply
> be queued and in fact will all be dropped except the last one
> (non-realtime signals are never stacked). The handler wi
On Tue, Jun 13, 2006 at 10:36:27PM -0400, Tom Lane wrote:
> * not clear whether the interrupt happens when waiting for I/O. I
> already mentioned that this would be a problem for EXPLAIN ANALYZE,
> but it might be no big deal for the other uses.
If we're going y UNIX signal semantics, in theory a
On Tue, Jun 13, 2006 at 11:13:55PM -0300, Marc G. Fournier wrote:
> >BTW, there's another FBSD performance odditiy I've run across. Running
> >
> >pg_dump -t email_contrib -COx stats | bzip2 > ec.sql.bz2 &
> >
> >which dumps the email_contrib table to bzip2 then to disk, the OS won't
> >use more t
Bruce Momjian writes:
> Right. What if the postmaster signals the backend once a second to do
> their reporting. I am not sure what the final solution will be, but we
> _need_ one based on the performance numbers I and others have seen.
> Could we have PGPROC have a reporting boolean that is se
On Tue, 13 Jun 2006, Jim Nasby wrote:
On Jun 12, 2006, at 10:38 AM, Kris Kennaway wrote:
FYI, the biggest source of contention is via semop() - it might be
possible to optimize that some more in FreeBSD, I don't know.
Yeah, I've seen PostgreSQL on FreeBSD fall over at high load with a lot
of
On Jun 12, 2006, at 10:38 AM, Kris Kennaway wrote:
FYI, the biggest source of contention is via semop() - it might be
possible to optimize that some more in FreeBSD, I don't know.
Yeah, I've seen PostgreSQL on FreeBSD fall over at high load with
a lot
of procs in either semwait or semlock.
On Tue, Jun 13, 2006 at 05:05:31PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Jim C. Nasby wrote:
> > >> Excellent. Did I miss discussion of that or have you not mentioned it?
> > >> I'm curious as to how you're fixing it...
> >
> > > The patches are in the hold
Tom Lane wrote:
> Bruce Momjian writes:
> > Jim C. Nasby wrote:
> >> Excellent. Did I miss discussion of that or have you not mentioned it?
> >> I'm curious as to how you're fixing it...
>
> > The patches are in the hold queue:
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Tha
> That's talking about the stats code, which has approximately
> zip to do with setproctitle (ps_status.c). But IIRC that
> patch is on hold because nobody particularly liked the
> approach it's taking. I think we should investigate
> rewriting the stats communication architecture entirely --
On Tue, Jun 13, 2006 at 04:35:24PM -0400, Tom Lane wrote:
> ... The main objection I see to this is that it replaces a kernel
> call that actually does some work with a kernel call to start a timer,
> plus possibly a later kernel call to actually do the work. Not clear
> that there's a win there.
Bruce Momjian writes:
> Jim C. Nasby wrote:
>> Excellent. Did I miss discussion of that or have you not mentioned it?
>> I'm curious as to how you're fixing it...
> The patches are in the hold queue:
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
That's talking about the stats code
Jim C. Nasby wrote:
> On Tue, Jun 13, 2006 at 02:10:15PM -0400, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > FWIW, getting turning off stats_command_string substantially reduced
> > > this contention, so it appears the issue is somewhere in the stats code.
> > > This code sends stats messages
On Tue, Jun 13, 2006 at 02:10:15PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > FWIW, getting turning off stats_command_string substantially reduced
> > this contention, so it appears the issue is somewhere in the stats code.
> > This code sends stats messages to a different process via a
Jim C. Nasby wrote:
> FWIW, getting turning off stats_command_string substantially reduced
> this contention, so it appears the issue is somewhere in the stats code.
> This code sends stats messages to a different process via a socket (or
> is it UDP?), with the intention that if the system gets he
On Mon, Jun 12, 2006 at 11:38:01AM -0400, Kris Kennaway wrote:
> On Mon, Jun 12, 2006 at 10:08:22AM -0500, Jim C. Nasby wrote:
> > On Mon, Jun 12, 2006 at 12:24:36AM -0400, Kris Kennaway wrote:
> > > On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> > > > On Sun, Jun 11, 2006 at 09:58
On Mon, Jun 12, 2006 at 10:08:22AM -0500, Jim C. Nasby wrote:
> On Mon, Jun 12, 2006 at 12:24:36AM -0400, Kris Kennaway wrote:
> > On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> > > On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
> > > > Kris Kennaway <[EMAIL PROTECTED]>
On Mon, Jun 12, 2006 at 12:24:36AM -0400, Kris Kennaway wrote:
> On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> > On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
> > > Kris Kennaway <[EMAIL PROTECTED]> writes:
> > > > On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wro
On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
> > Kris Kennaway <[EMAIL PROTECTED]> writes:
> > > On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
> > >> Let's see the evidence.
> >
> > > The calls to setproctitle
On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
> >> Let's see the evidence.
>
> > The calls to setproctitle() (it looks like 4 setproctitle syscalls per
> > DB query) are causing co
On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
> > On Sun, 11 Jun 2006, Kris Kennaway wrote:
> >> Why does postgresql change its process title so frequently and how can
> >> this be disabled? Profiling suggests it's a fairly serious
> >> performance bottleneck.
>
> Let's see the eviden
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
>> Let's see the evidence.
> The calls to setproctitle() (it looks like 4 setproctitle syscalls per
> DB query) are causing contention on the Giant lock 25% of the time on
> a dual p4 + HTT. Disa
> On Sun, 11 Jun 2006, Kris Kennaway wrote:
>> Why does postgresql change its process title so frequently and how can
>> this be disabled? Profiling suggests it's a fairly serious
>> performance bottleneck.
Let's see the evidence.
regards, tom lane
--
The only way that I'm aware of for disabling this is at compile time ...
after running configure, you want to modify:
src/include/pg_config.h
and undef HAVE_SETPROCTITLE ...
I'm CC'ng -hackers about this though, since I think you are the first to
point to setproctitle() as being a serious p
41 matches
Mail list logo
