From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, lutzeb(at)aeccom(dot)com, pgsql-performance(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com> |
Subject: | Re: Wierd context-switching issue on Xeon |
Date: | 2004-04-19 22:55:34 |
Message-ID: | 29784.1082415334@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> I've got a quad 2.8Ghz MP Xeon (IBM x445) that I could test on. Does
>> anyone have a test set that can reliably reproduce the problem?
> Unfortunately we can't seem to come up with one.
> It does seem to require a database which is in the many GB (> 10GB), and a
> situation where a small subset of the data is getting hit repeatedly by
> multiple processes.
I do not think a large database is actually necessary; the test case
Josh's client has is only hitting a relatively small amount of data.
The trick seems to be to cause lots and lots of ReadBuffer/ReleaseBuffer
activity without much else happening, and to do this from multiple
backends concurrently.
I believe the best way to make this happen is a lot of relatively simple
(but not short) indexscan queries that in aggregate touch just a bit
less than shared_buffers worth of data. I have not tried to make a
self-contained test case, but based on what I know now I think it should
be possible.
I'll give this a shot later tonight --- it does seem that trying to
reproduce the problem on different kinds of hardware is the next useful
step we can take.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-20 00:01:56 | Re: Wierd context-switching issue on Xeon |
Previous Message | Josh Berkus | 2004-04-19 21:55:04 | Re: Wierd context-switching issue on Xeon |