On Wed, Oct 10, 2012 at 11:44:50AM -0300, Claudio Freire wrote:
> On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas <sthomas@optionshouse.com> wrote:
> > On 10/09/2012 06:30 PM, Craig James wrote:
> >
> >> ra:8192 walb:1M ra:256 walb:1M ra:256 walb:256kB
> >> ---------------- ---------------- -----------------
> >> -c -t Run1 Run2 Run3 Run4 Run5 Run6 Run7 Run8 Run9
> >> 40 2500 4261 3722 4243 9286 9240 5712 9310 8530 8872
> >> 50 2000 4138 4399 3865 9213 9351 9578 8011 7651 8362
> >
> >
> > I think I speak for more than a few people here when I say: wat.
> >
> > About the only thing I can ask, is: did you make these tests fair? And by
> > fair, I mean:
> >
> > echo 3 > /proc/sys/vm/drop_caches
> > pg_ctl -D /your/pg/dir restart
>
> Yes, I was thinking the same. Especially if you check the tendency to
> perform better in higher-numbered runs. But, as you said, that doesn't
> explain that jump to twice the TPS. I was thinking, and I'm not
> pgbench expert, could it be that the database grows from run to run,
> changing performance characteristics?
>
> > My head hurts.
>
> I'm just confused. No headache yet.
>
> But really interesting numbers in any case. It these results are on
> the level, then maybe the kernel's read-ahead algorithm isn't as
> fool-proof as we thought? Gotta read the source. BRB
Well, I have exactly the same setup here:
new: 2x4-core Intex Xeon E5620 2.40 GHz
Let me know if you want any tests run, on SSDs or magnetic disk. I do
have hyperthreading enabled, and Greg Smith benchmarked my server and
said it was good.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
