Re: Seeing context switch storm with 10/13 snapshot of
От | Robert Creager |
---|---|
Тема | Re: Seeing context switch storm with 10/13 snapshot of |
Дата | |
Msg-id | 20051020165407.000009c8@C118181.stortek.com обсуждение исходный текст |
Ответ на | Re: Seeing context switch storm with 10/13 snapshot of (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Seeing context switch storm with 10/13 snapshot of
|
Список | pgsql-hackers |
On Thu, 20 Oct 2005 23:28:21 +0100 Simon Riggs <simon@2ndquadrant.com> wrote: > On Thu, 2005-10-20 at 14:59 -0600, Robert Creager wrote: > > On Thu, 20 Oct 2005 21:19:18 +0100 > > Simon Riggs <simon@2ndquadrant.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. I modified the setup to create the first table, then selected it into the second two tables, all in the same database. Created three unique indexes (when I didn't, there was no CS issue). > > 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). The CS is the same on both 7.4.1 and 8.1b3 (with 8.1b3 showing 100k and 7.4.1 showing 170k using three clients). I double checked the scripts to make sure... Cheers, Rob
В списке pgsql-hackers по дате отправления: