From: M. Edward (Ed) Borasky <znmeb@cesmail.net>
To: pgsql-performance@postgresql.org
Subject: Re: understanding postgres issues/bottlenecks
Date: Wed, 07 Jan 2009 07:35:23 -0800
Message-ID: <4964CBBB.5030806@cesmail.net> (raw)
In-Reply-To: <200901070931.26788.simonw@zynet.net>
References: <49638BE9.2030701@gmail.com>
<72dbd3150901061533o5f8601cau389ceaf0ad6840cd@mail.gmail.com>
<49642CC6.4020902@cesmail.net>
<200901070931.26788.simonw@zynet.net>
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. :)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: znmeb@cesmail.net
Subject: Re: understanding postgres issues/bottlenecks
In-Reply-To: <4964CBBB.5030806@cesmail.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox