Re: postgresql 8.3 tps rate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Greg Smith wrote:

> I'm not sure what is going on with your system, but the advice showing
> up earlier in this thread is well worth heeding here:  if you haven't
> thoroughly proven that your disk setup works as expected on simple I/O
> tests such as dd and bonnie++, you shouldn't be running pgbench yet.
> It's not a tranparent benchmark unless you really understand what it's
> doing, and you can waste endless time chasing phantom database setup
> problems that way when you should be staring at hardware, driver, or OS
> level ones instead.  Do you know the disks are working as they should
> here?  Does the select-only pgbench give you reasonable results?

Actually, this isn't so much a 'pgbench' exercise as it is a source of
'real-world application' data for my Linux I/O performance visualization
tools. I've done 'iozone' tests, though not recently. But what I'm
building is an I/O analysis toolset, not a database application. So I am
"staring at hardware, driver or OS level" issues. :) To be more precise,
I'm using block I/O layer tools, which are "beneath" the filesystem
layer but "above" the driver and hardware levels.

What you might find interesting is that, when I presented the earlier
(iozone) test results at the Computer Measurement Group meeting in Las
Vegas in December, there were two disk drive engineers in the audience,
from, IIRC, Fujitsu. When they saw my results showing all four Linux
schedulers yielding essentially the same performance metrics using some
fairly tight statistical significance tests, they told me that it was
because the drive was re-ordering operations according to its own
internal scheduler!

I haven't had a chance to investigate that in any detail yet, but I
assume that they knew what they were talking about. The drive in
question is an off-the-shelf unit that I got at CompUSA as part of a
system that I had them build. In any event, it's *not* a "server-grade
I/O subsystem", it's a single disk drive designed for "home desktop PC"
use cases. In short, I don't expect server-grade TPS values.

I did capture some 'iostat' data after I moved the 'pgbench' database
back into the main partition where the rest PostgreSQL database lives.
As I expected, the device and partition utilizations were in the high 90
percent range.

I don't have the bandwidth figures from 'iostat' handy, but if the
utilization is 98.4 percent, they may be the best I can get out of the
drive with the xfs filesystem and the cfq scheduler. And the choice of
scheduler might not matter. And the choice of filesystem might not
matter. I may be getting all the drive can do.

-- 
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.

-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux