From: | Sébastien Lorion <sl(at)thestrangefactory(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Amazon High I/O instances |
Date: | 2012-08-24 04:22:47 |
Message-ID: | CAGa5y0OpZy6fTPvrO-t2QfUqoEzjpHqqPO7G+3k8NB3eHeSYXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I will be setting up an instance in the coming days and post the results
here.
While reading on the subject, I found this interesting discussion on
YCombinator:
http://news.ycombinator.com/item?id=4264754
Sébastien
On Thu, Aug 23, 2012 at 2:41 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 08/23/12 11:24 AM, Sébastien Lorion wrote:
>
>> I think both kind of tests (general and app specific) are complementary
>> and useful in their own way. At a minimum, if the general ones fail, why go
>> to the expenses of doing the specific ones ? Setting up a meaningful
>> application test can take a lot of time and it can be hard to pinpoint
>> exactly where in the stack the performance drops occur. The way I see it,
>> synthetic benchmarks allow to isolate somewhat the layers and serve as a
>> base to validate application tests done later on. It surprises me that
>> asking for the general perf behavior of a platform is controversial.
>>
>
> I don't use AWS at all. But, it shouldnt take more than a couple hours
> to spin up an instance, populate a pgbench database and run a series of
> pgbench runs against it, and do the same against any other sort of system
> you wish to use as your reference.
>
> I like to test with a database about twice the size of the available
> memory if I'm testing IO, and I've found that pgbench -i -s ####, for
> ####=10000 it generates a 1 billion row table and uses about 150GB (and a
> hour or so to initialize on fast IO hardware). I then run pgbench with -c
> of about 2-4X the cpu/thread count, and -j of about -c/16, and a -t of at
> least 10000 (so each client connection runs 10000 transactions).
>
> on a modest but decent 2U class 2-socket dedicated server with a decent
> raid card and raid10 across enough spindles, I can see numbers as high as
> 5000 transactions/second with 15krpm rust, and 7000-8000 with a couple MLC
> SSD's striped. trying to raid10 a bunch of SATA 7200 disks gives numbers
> more like 1000. using host based raid, without a write-back cache in the
> raid card, gives numbers about 1/2 the above. the IOPS during these tests
> hit around 12000 or 15000 small writes/second.
>
> doing this level of IO on a midsized SAN can often cause the SAN CPU to
> run at 80%+ so if there's other activity on the SAN from other hosts, good
> luck.
>
> in a heavily virtualized shared-everything environment, I'm guessing your
> numbers will be all over the place and difficult to achieve consistency.
>
>
> --
> john r pierce N 37, W 122
> santa cruz ca mid-left coast
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-general<http://www.postgresql.org/mailpref/pgsql-general>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-08-24 04:34:04 | Re: FETCH in subqueries or CTEs |
Previous Message | Craig Ringer | 2012-08-24 03:14:11 | Re: Postgresql 9.1 on VMWare ESXi 5.0 |