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@gmail.com> wrote:
> On Sat, Apr 30, 2011 at 4:51 AM, Hsien-Wen Chu <chu.hsien.wen@gmail.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
