On Mar 29, 2007, at 2:19 PM, Tom Lane wrote:
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.
software developer
615-296-0838
emma(r)
