On Wed, Oct 10, 2012 at 7:44 AM, Claudio Freire <klaussfreire@xxxxxxxxx> wrote:
I showed the exact commands I used -- if it's not there, I didn't do it. So the answer is no, I didn't drop caches.
On the other hand, I wanted to know what happened on cold start and after running for a while. Running pgbench once isn't as interesting as running it three times.
On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> 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
I showed the exact commands I used -- if it's not there, I didn't do it. So the answer is no, I didn't drop caches.
On the other hand, I wanted to know what happened on cold start and after running for a while. Running pgbench once isn't as interesting as running it three times.
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
Big numbers, little numbers ... I'm just reporting what pgbench tells me and how I got them. I'm good at chemical databases, you guys are the Postgres performance experts.
