From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | Charles Sprickman <spork(at)bway(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: SAN/NAS options |
Date: | 2005-12-16 22:49:55 |
Message-ID: | 43A34493.4020204@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jim C. Nasby wrote:
> On Wed, Dec 14, 2005 at 08:28:56PM +1300, Mark Kirkwood wrote:
>
>>Another interesting thing to try is rebuilding the database ufs
>>filesystem(s) with 32K blocks and 4K frags (as opposed to 8K/1K or
>>16K/2K - can't recall the default on 4.x). I found this to give a factor
>>of 2 speedup on random disk access (specifically queries doing indexed
>>joins).
>
>
> Even if you're doing a lot of random IO? I would think that random IO
> would perform better if you use smaller (8K) blocks, since there's less
> data being read in and then just thrown away that way.
>
>
Yeah, that's what I would have expected too! but the particular queries
I tested do a ton of random IO (correlation of 0.013 on the join column
for the big table). I did wonder if the gain has something to do with
the underlying RAID stripe size (64K or 256K in my case), as I have only
tested the 32K vs 8K/16K on RAIDed systems.
I guess for a system where the number of concurrent users give rise to
memory pressure, it will cause more thrashing of the file buffer cache,
much could be a net loss.
Still worth trying out I think, you will know soon enough if it is a win
or lose!
Note that I did *not* alter Postgres page/block size (BLCKSZ) from 8K,
so no dump/reload is required to test this out.
cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2005-12-16 22:51:03 | Re: SAN/NAS options |
Previous Message | Jim C. Nasby | 2005-12-16 22:45:12 | Re: Overriding the optimizer |