From: | Erik Jones <erik(at)myemma(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Shared buffers, db transactions commited, and write IO on Solaris |
Date: | 2007-03-29 19:49:48 |
Message-ID: | F155EEAC-37E5-4CF8-B355-77FFAE79DECD@myemma.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mar 29, 2007, at 2:19 PM, Tom Lane wrote:
> Erik Jones <erik(at)myemma(dot)com> writes:
>> One very important thing to note here is that the number, or rather
>> rate, of disk writes has not changed. It's the volume of data in
>> those writes that has dropped, along with those transaction
>> mysterious counts.
>
> Hmm. I'm suddenly thinking about the stats collector: in existing
> 8.2.x
> releases it's got a bug that causes it to write the collected-stats
> file
> much too often. If you had done something that would shrink the size
> of the stats file, that might explain this observation. Do you have
> stats_reset_on_server_start turned on?
Nope.
>
> The drop in reported transaction rate is still baffling though.
> Are you
> sure you're really doing the same amount of work? Can you estimate
> what
> you think the transaction rate *should* be from a what-are-your-
> clients-
> doing perspective?
Unfortunately, I can't think of any way to do that. Our app is made
up of a lot of different components and not all of them are even
directly client driven. For the client driven portions of the app
any given web request can contain anywhere from around 10 to
sometimes over 50 different xacts (and, that just a guesstimate).
Also, we didn't start tracking xact counts via pg_stat_database until
about two months ago when we were in IO bound hell and we actually
thought that the really big xact #s were normal for our app as that
was the first and, thus, only numbers we had to work with.
Also, another metric we track is to take a count from
pg_stat_activity of queries running longer than 1 second every five
minutes. Before these recent changes it wasn't uncommon to see that
count start to seriously stack up to over 200 at times with write
intensive queries hanging out for sometimes 30 minutes or more (we'd
often end having to kill them...). Since we upped the shared buffers
and turned on forcedirectio for our fs mount, that number has stayed
under 50 and has only crossed 20 once.
erik jones <erik(at)myemma(dot)com>
software developer
615-296-0838
emma(r)
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri | 2007-03-29 22:15:11 | Re: Shared buffers, db transactions commited, and write IO on Solaris |
Previous Message | Tom Lane | 2007-03-29 19:19:49 | Re: Shared buffers, db transactions commited, and write IO on Solaris |