Simon Waters wrote: > On Wednesday 07 January 2009 04:17:10 M. Edward (Ed) Borasky wrote: >> 1. The package it lives in is called "sysstat". Most Linux distros do >> *not* install "sysstat" by default. Somebody should beat up on them >> about that. :) > > Hehe, although sysstat and friends did have issues on Linux for a long time. > Nothing worse than misleading stats, so I suspect it lost a lot of friends > back then. It is a lot better these days when most of the "Unix" software > targets Linux first, and other kernels second. I'm unfortunately familiar with that "episode", which turned out to be bugs in the Red Hat Linux kernels / drivers. I don't remember the exact versions, although there was at least one of them shipped at one time as part of RHEL 3. I may be wrong, but I don't think Sebastien ever had to change any of *his* code in "sysstat" -- I think he had to wait for Red Hat. :) > > Aside from all the advice here about system tuning, as a system admin I'd also > ask is the box doing the job you need? And are you looking at the Postgres > log (with logging of slow queries) to see that queries perform in a sensible > time? I'd assume with the current performance figure there is an issue > somewhere, but I've been to places where it was as simple as adding one > index, or even modifying an index so it does what the application developer > intended instead of what they ask for ;) > Yeah ... the issues of application response time and throughput, cost of adding hardware to the box(es) vs. cost of changing the application, changes in demand for the server over time, etc., are what make capacity planning "fun". Squeezing the last megabyte per second out of a RAID array is the easy stuff. :) -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
