Message-ID: <4389A4D4.6030203@pse-consulting.de>
Date: Sun, 27 Nov 2005 13:21:40 +0100
From: Andreas Pflug <pgadmin@pse-consulting.de>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: David Lang <dlang@invendra.net>
CC: pgsql-performance@postgresql.org
Subject: Re: Open request for benchmarking input
References: <Pine.LNX.4.62.0511260745370.2790@qnivq.ynat.uz>
In-Reply-To: <Pine.LNX.4.62.0511260745370.2790@qnivq.ynat.uz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Lang wrote:
>> These boxes don't look like being designed for a DB server. The first 
>> are very CPU bound, and the third may be a good choice for very large 
>> amounts of streamed data, but not optimal for TP random access.
> 
> 
> I don't know what you mean when you say that the first ones are CPU 
> bound, they have far more CPU then they do disk I/O
> 
> however I will agree that they were not designed to be DB servers, they 
> weren't. they happen to be the machines that I have available.

That was what I understood from the specs.
> 
> they only have a pair of disks each, which would not be reasonable for 
> most production DB uses, and they have far more CPU then is normally 
> reccomended. So I'll have to run raid 0 instead of 0+1 (or not use raid) 
> which would be unacceptable in a production environment, but can still 
> give some useful info.
 >
> the 5th box _was_ purchased to be a DB server, but one to store and 
> analyse large amounts of log data, so large amounts of data storage were 
> more important then raw DB performance (although we did max out the RAM 
> at 16G to try and make up for it). it was a deliberate price/performance 
> tradeoff. this machine ran ~$20k, but a similar capacity with SCSI 
> drives would have been FAR more expensive (IIRC a multiple of 4x or more 
> more expensive).

That was my understanding too. For this specific requirement, I'd 
probably design the server the same way, and running OLAP benchmarks 
against it sounds very reasonable.

> 
>> Hopefully, when publicly visible benchmarks are performed, machines 
>> are used that comply with common engineering knowledge, ignoring those 
>> guys who still believe that sequential performance is the most 
>> important issue on disk subsystems for DBMS.
> 
> 
> are you saying that I shouldn't do any benchmarks becouse the machines 
> aren't what you would consider good enough?
> 
> if so I disagree with you and think that benchmarks should be done on 
> even worse machines, but should also be done on better machines. (are 
> you volunteering to provide time on better machines for benchmarks?)
> 
> not everyone will buy a lot of high-end hardware before they start 
> useing a database. in fact most companies will start with a database on 
> lower end hardware and then as their requirements grow they will move to 
> better hardware. I'm willing to bet that what I have available is better 
> then the starting point for most places.
> 
> Postgres needs to work on the low end stuff as well as the high end 
> stuff or people will write their app to work with things that DO run on 
> low end hardware and they spend much more money then is needed to scale 
> the hardware up rather then re-writing their app.

I agree that pgsql runs on low end stuff, but a dual Opteron with 
2x15kSCSI isn't low end, is it? The CPU/IO performance isn't balanced 
for the total cost, you probably could get a single CPU/6x15kRPM machine 
for the same price delivering better TP performance in most scenarios.

Benchmarks should deliver results that are somewhat comparable. If 
performed on machines that don't deliver a good CPU/IO power balance for 
the type of DB load being tested, they're misleading and hardly usable 
for comparision purposes, and even less for learning how to configure a 
decent server since you might have to tweak some parameters in an 
unusual way.

Regards,
Andreas