From: Josh Berkus <josh@agliodbs.com>
To: Erik Jones <erik@myemma.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Shared buffers, db transactions commited, and write IO on Solaris
Date: Fri, 30 Mar 2007 14:46:35 -0700
Message-ID: <200703301446.35858.josh@agliodbs.com> (raw)
In-Reply-To: <39BA9EF6-4928-4128-B4BB-A8DE2C536053@myemma.com>
References: <9B7F4B34-7E96-4501-BCE0-D0BED739530A@myemma.com>
<200703291723.24061.josh@agliodbs.com>
<39BA9EF6-4928-4128-B4BB-A8DE2C536053@myemma.com>
Erik,
> You'er welcome! However, I believe our situation is very different
> from what you're testing if I understand you correctly. Are you
> saying that you're entire database will fit in memory? If so, then
> these are very different situations as there is no way ours could
> ever do that. In fact, I'm not sure that forcedirectio would really
> net you any gain in that situation as the IO service time will be
> basically nil if the filesystem cache doesn't have to page which I
> would think is why your seeing what you are.
Even more interesting. I guess we've been doing too much work with
benchmark workloads, which tend to be smaller databases.
Thing is, there's *always* I/O for a read/write database. If nothing else,
updates have to be synched to disk.
Anyway ... regarding the mystery transactions ... are you certain that it's
not your application? I can imagine that, if your app has a fairly tight
retry interval for database non-response, that I/O sluggishness could
result in commit attempts spinning out of control.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
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: josh@agliodbs.com, erik@myemma.com
Subject: Re: Shared buffers, db transactions commited, and write IO on Solaris
In-Reply-To: <200703301446.35858.josh@agliodbs.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