pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Dimitri <dimitrik.fr@gmail.com>
To: Erik Jones <erik@myemma.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Shared buffers, db transactions commited, and write IO on Solaris
Date: Fri, 30 Mar 2007 15:14:35 +0200
Message-ID: <5482c80a0703300614x1fe7d9ccy2d414ed87f98db3d@mail.gmail.com> (raw)
In-Reply-To: <84D24979-AF34-4875-9AFB-DD4A7814B99A@myemma.com>
References: <9B7F4B34-7E96-4501-BCE0-D0BED739530A@myemma.com>
	<23286.1175184996@sss.pgh.pa.us>
	<E49400AB-D46D-4BB8-9F27-65F5AB06F40E@myemma.com>
	<5482c80a0703291041gbf95cd9v95e17e271293ae8e@mail.gmail.com>
	<606E8491-AAFB-493E-8FFA-FF26D6DD5ACE@myemma.com>
	<5482c80a0703291515i7c05ba28l6f7240ebb5d2b837@mail.gmail.com>
	<84D24979-AF34-4875-9AFB-DD4A7814B99A@myemma.com>

>
> You are right in that the page size constraint is lifted in that
> directio cuts out the VM filesystem cache.  However, the Solaris
> kernel still issues io ops in terms of its logical block size (which
> we have at the default 8K).  It can issue io ops for fragments as
> small as 1/8th of the block size, but Postgres issues its io requests
> in terms of the block size which means that io ops from Postgres will
> be in 8K chunks which is exactly what we see when we look at our
> system io stats.  In fact, if any io request is made that isn't a
> multiple of 512 bytes (the disk sector size), the file system
> switches back to the buffered io.

Oh, yes, of course! yes, you still need to respect multiple of 512
bytes block size on read and write - sorry, I was tired :)

Then it's seems to be true - default XLOG block size is 8K, means for
every even small auto-committed transaction we should write 8K?... Is
there any reason to use so big default block size?...

Probably it may be a good idea to put it as 'initdb' parameter? and
have such value per database server?

Rgds,
-Dimitri

>
> >
> > However, to understand TX number mystery I think the only possible
> > solution
> > is to reproduce a small live test:
> >
> > (I'm sure you're aware you can mount/unmount forcedirectio
> > dynamically?)
> >
> > during stable workload do:
> >
> >   # mount -o remount,logging  /path_to_your_filesystem
> >
> > and check if I/O volume is increasing as well TX numbers
> > than come back:
> >
> >   # mount -o remount,forcedirectio  /path_to_your_filesystem
> >
> > and see if I/O volume is decreasing as well TX numbers...
>
> That's an excellent idea and I'll run it by the rest of our team
> tomorrow.
>
> erik jones <erik@myemma.com>
> software developer
> 615-296-0838
> emma(r)
>
>
>
>



view thread (22+ messages)  latest in thread

Message-ID: <5482c80a0703300614x1fe7d9ccy2d414ed87f98db3d@mail.gmail.com>
Permalink:  ../5482c80a0703300614x1fe7d9ccy2d414ed87f98db3d@mail.gmail.com/
Also on:    postgresql.org/message-id/5482c80a0703300614x1fe7d9ccy2d414ed87f98db3d@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: dimitrik.fr@gmail.com, erik@myemma.com, tgl@sss.pgh.pa.us
  Subject: Re: Shared buffers, db transactions commited, and write IO on Solaris
  In-Reply-To: <5482c80a0703300614x1fe7d9ccy2d414ed87f98db3d@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox