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
