Re: Shared buffers, db transactions commited, and write IO on Solaris
От | Erik Jones |
---|---|
Тема | Re: Shared buffers, db transactions commited, and write IO on Solaris |
Дата | |
Msg-id | E49400AB-D46D-4BB8-9F27-65F5AB06F40E@myemma.com обсуждение исходный текст |
Ответ на | Re: Shared buffers, db transactions commited, and write IO on Solaris (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Shared buffers, db transactions commited, and write IO on Solaris
Re: Shared buffers, db transactions commited, and write IO on Solaris Re: Shared buffers, db transactions commited, and write IO on Solaris |
Список | pgsql-performance |
On Mar 29, 2007, at 11:16 AM, Tom Lane wrote:
Erik Jones <erik@myemma.com> writes:We've recently made a couple changes to our system that have resultedin a drastic increase in performance as well as some very confusingchanges to the database statistics, specificallypg_stat_database.xact_commit. Here's the details:I'm kinda boggled too. I can see how increasing shared buffers couldresult in a drastic reduction in write rate, if the working set of yourqueries fits in the new space but didn't fit in the old. I have no ideahow that leads to a drop in number of transactions committed though.It doesn't make sense that autovac would run less frequently, becauseit's driven by number of tuples changed not number of disk writes; andthat could hardly account for a 10x drop anyway.Did you by any chance take note of exactly which processes weregenerating all the I/O or the CPU load?
Well, wrt to the CPU load, as I said, we're pretty sure that's autovac as we still get spikes that hit about the same threshold, after which cache hits go up dramatically and the spikes just don't last two days anymore.
As far as the procs responsible for the writes go, we were unable to see that from the OS level as the guy we had as a systems admin last year totally screwed us with the way he set up the SunCluster on the boxes and we have been unable to run Dtrace which has left us watching a lot of iostat. However, we did notice a direct correlation between write spikes and "write intensive" queries like large COPYs, UPDATEs, and INSERTs.
В списке pgsql-performance по дате отправления: