From: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Hsien-Wen Chu <chu(dot)hsien(dot)wen(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql? |
Date: | 2011-05-06 10:53:07 |
Message-ID: | BANLkTin-s6nmC0Fqexm3HOnA3qJuXKAA9A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
You should rather consider VxFS tuning - it has an auto-discovery for
DIRECT I/O according the block size. Just change this setting to 8K or
16-32K depending on your workload - then all I/O operations with a
bigger block size will be executed in DIRECT mode and bypass FS cache
(which logical as usually it'll correspond to a full scan or a seq
scan of some data), while I/O requests with smaller blocks will remain
cached which is very useful as it'll mainly cache random I/O (mainly
index access)..
With such a tuning I've got over %35 performance improvement comparing
to any other states (full DIRECT or fully cached).
Rgds,
-Dimitri
Rgds,
-Dimitri
On 5/5/11, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Apr 30, 2011 at 4:51 AM, Hsien-Wen Chu <chu(dot)hsien(dot)wen(at)gmail(dot)com>
> wrote:
>> since the block size is 8k for the default, and it consisted with many
>> tuple/line; as my understand, if any tuple/line is changed(maybe
>> update, insert, delete). the block will be marked as dirty block. and
>> then it will be flashed to disk by bgwriter.
>
> True...
>
>> so my question is if the data block(8k) is aligned with the file
>> system block? if it is aligned with file system block, so what's the
>> potential issue make it is not safe for direct io. (please assume
>> vxfs, vxvm and the disk sector is aligned ).please correct me if any
>> incorrect.
>
> It's not about safety - it's about performance. On a machine with
> 64GB of RAM, a typical setting for shared_buffers set to 8GB. If you
> start reading blocks into the PostgreSQL cache - or writing them out
> of the cache - in a way that bypasses the filesystem cache, you're
> going to have only 8GB of cache, instead of some much larger amount.
> More cache = better performance.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2011-05-06 15:15:38 | Re: REINDEX takes half a day (and still not complete!) |
Previous Message | Tom Lane | 2011-05-05 20:27:15 | Re: Poor query plan chosen in 9.0.3 vs 8.3.7 |