On Mon, Mar 5, 2012 at 9:56 AM, Craig James <cjames@xxxxxxxxxxxxxx> wrote: > On Sun, Mar 4, 2012 at 10:36 AM, Rory Campbell-Lange > <rory@xxxxxxxxxxxxxxxxxx> wrote: >> >> We do have complex transactions, but I haven't benchmarked the >> performance so I can't describe it. Few of the databases are at the many >> million row size at the moment, and we are moving to an agressive scheme >> of archiving old data, so we hope to keep things fast. >> >> However I thought 15k disks were a pre-requisite for a fast database >> system, if one can afford them? I assume if all else is equal the 1880 >> controller will run 20-40% faster with 15k disks in a write-heavy >> application. Also I would be grateful to learn if there is a good reason >> not to use 2.5" SATA disks. > > > Without those benchmarks, you can't really say what "fast" means. There are > many bottlenecks that will limit your database's performance; the disk's > spinning rate is just one of them. Memory size, memory bandwidth, CPU, CPU > cache size and speed, the disk I/O bandwidth in and out, the disk RPM, the > presence of a BBU controller ... any of these can be the bottleneck. If you > focus on the disk's RPM, you may be fixing a bottleneck that you'll never > reach. > > We 12 inexpensive 7K SATA drives with an LSI/3Ware 9650SE and a BBU, and > have been very impressed by the performance. 8 drives in RAID10, two in > RAID1 for the WAL, one for Linux and one spare. This is on an 8-core system > with 12 GB memory: > > pgbench -i -s 100 -U test > pgbench -U test -c ... -t ... > > -c -t TPS > 5 20000 3777 > 10 10000 2622 > 20 5000 3759 > 30 3333 5712 > 40 2500 5953 > 50 2000 6141 Just wondering what your -c -t etc settings were, if the tests were long enough to fill up your RAID controllers write cache or not. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
