From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
---|---|
To: | Craig James <cjames(at)emolecules(dot)com> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Hyperthreading (was: Two identical systems, radically different performance) |
Date: | 2012-10-10 12:52:37 |
Message-ID: | 50756F95.7040006@optionshouse.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
Between every test to make sure shared buffers and the OS inode cache
was empty before the start of each test? If you're using that bash-style
for-loop you attached earlier, probably not. Still though, I don't think
that would account for this much variance between having read-ahead at
8M as opposed to 256kb.
My head hurts.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2012-10-10 13:09:56 | Re: shared_buffers/effective_cache_size on 96GB server |
Previous Message | François Beausoleil | 2012-10-10 12:38:28 | Re: Ways to speed up ts_rank |