From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Creager <Robert(dot)Creager(at)Sun(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PGHackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Seeing context switch storm with 10/13 snapshot of |
Date: | 2005-10-20 22:28:21 |
Message-ID: | 1129847301.8300.846.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2005-10-20 at 14:59 -0600, Robert Creager wrote:
> On Thu, 20 Oct 2005 21:19:18 +0100
> Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> > Try this to recreate the problem:
> > http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
> >
>
> Yup, that does it. Three hits the level I see with my application ~100k. Two
> hits about 50k, one does nothing (< 1k).
OK, good. IYKWIM
Can you try a slight modification?
Run 3 threads, but against 3 different otherwise identical test tables
created using a name-only mod of the test script. e.g. test_data1, 2 and
3.
This will hit a different pattern of lwlocks.
If the CS is the same, then it will tell us that the issue is not data
dependent. If the CS drops, it tells us that it is an activity performed
on the precise data blocks rather than the shared data structures which
is the issue. That would then account for why the effect appears to come
and go in your own application, because the effect is actually dependant
on the data distribution (which presumably varies in your tables).
Just trying to more tightly bracket the failure-case behaviour....
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Brown | 2005-10-20 22:42:10 | Re: Question about Ctrl-C and less |
Previous Message | Simon Riggs | 2005-10-20 22:03:47 | Re: Spinlocks, yet again: analysis and proposed patches |