"Jignesh K. Shah" <j.k.s...@sun.com> wrote: > On 03/11/09 18:27, Kevin Grittner wrote: >> "Jignesh K. Shah" <j.k.s...@sun.com> wrote: >>> Rerunning similar tests on a 64-thread UltraSPARC T2plus based >>> server config >> >>> (IO is not a problem... all in RAM .. no disks): >>> Time:Users:Type:TPM: Response Time >>> 60: 100: Medium Throughput: 10552.000 Avg Medium Resp: 0.006 >>> 120: 200: Medium Throughput: 22897.000 Avg Medium Resp: 0.006 >>> 180: 300: Medium Throughput: 33099.000 Avg Medium Resp: 0.009 >>> 240: 400: Medium Throughput: 44692.000 Avg Medium Resp: 0.007 >>> 300: 500: Medium Throughput: 56455.000 Avg Medium Resp: 0.007 >>> 360: 600: Medium Throughput: 67220.000 Avg Medium Resp: 0.008 >>> 420: 700: Medium Throughput: 77592.000 Avg Medium Resp: 0.009 >> I'm a lot more interested in what's happening between 60 and 180 than >> over 1000, personally. If there was a RAID involved, I'd put it down >> to better use of the numerous spindles, but when it's all in RAM it >> makes no sense. > The problem is the CPUs are not all busy there is plenty of idle cycles > since PostgreSQL ends up in situations where they are all waiting for
> lockacquires for exclusive.. Precisely. This is the area where it seems there is the most to gain. The area you're looking at seems to have less than a 2X gain available. This part of the curve clearly has much more. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
