Re: Open request for benchmarking input - Mailing list pgsql-performance
From | Andreas Pflug |
---|---|
Subject | Re: Open request for benchmarking input |
Date | |
Msg-id | 4389A4D4.6030203@pse-consulting.de Whole thread Raw |
In response to | Open request for benchmarking input (David Lang <dlang@invendra.net>) |
Responses |
Re: Open request for benchmarking input
|
List | pgsql-performance |
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
pgsql-performance by date: