Skip site navigation (1) Skip section navigation (2)

Re: Shared buffers, db transactions commited, and write IO on Solaris

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 (view raw or flat)
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)



In response to

pgsql-performance by date

Next:From: DimitriDate: 2007-03-29 22:15:11
Subject: Re: Shared buffers, db transactions commited, and write IO on Solaris
Previous:From: Tom LaneDate: 2007-03-29 19:19:49
Subject: Re: Shared buffers, db transactions commited, and write IO on Solaris

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group