Tom Lane wrote:
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > Ok, here is a pgbench (-s 10) result on an AIX 5L box (4 way).
> > "7.2 with patch" is for the previous patch. "7.2 with patch (revised)"
> > is for the this patch. I see virtually no improvement.
>
> If anything, the revised patch seems to make things slightly worse :-(.
> That agrees with my measurement on a single CPU.
>
> I am inclined to use the revised patch anyway, though, because I think
> it will be less prone to starvation (ie, a process repeatedly being
> awoken but failing to get the lock). The original form of lwlock.c
> guaranteed that a writer could not be locked out by large numbers of
> readers, but I had to abandon that goal in the first version of the
> patch. The second version still doesn't keep the writer from being
> blocked by active readers, but it does ensure that readers queued up
> behind the writer won't be released. Comments?
OK, so now we know that while the new lock code handles the select(1)
problem better, we also know that on AIX the old select(1) code wasn't
as bad as we thought.
As to why we don't see better numbers on AIX, we are getting 100tps,
which seems pretty good to me. Tatsuo, were you expecting higher than
100tps on that machine? My hardware is at listed at
http://candle.pha.pa.us/main/hardware.html and I don't get over 16tps.
I believe we don't see improvement on SMP machines using pgbench because
pgbench, at least at high scaling factors, is really testing disk i/o,
not backend processing speed. It would be interesting to test pgbench
using scaling factors that allowed most of the tables to sit in shared
memory buffers. Then, we wouldn't be testing disk i/o and would be
testing more backend processing throughput. (Tom, is that true?)
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
