SEO

Hi.

Has anybody tried the new Sun "cool-thread" servers t1000/t2000 from
Sun? I'd love to see benchmarks with Solaris 10 and pg 8.1.

regards
Claus

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

I may be able to organize a test on a T2000 if someone could give
advice as to an appropriate test to run...

Cheers,

Neil

On 3/6/06, Claus Guttesen <kometen@gmail.com> wrote:
> Hi.
>
> Has anybody tried the new Sun "cool-thread" servers t1000/t2000 from
> Sun? I'd love to see benchmarks with Solaris 10 and pg 8.1.
>
> regards
> Claus
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Suggestions for benchmarks on Sun Fire T2000...

* Don't try DSS or TPC-H type of test with Postgres on Sun Fire T2000

Since such queries tend to have one connection, it will perform badly
with Postgre since it will use only one hardware virtual CPU of the
available 32 virtual CPU on Sun Fire T2000. (Oracle/DB2 have ways of
breaking the queries into multiple processes and hence use multiple
virtual CPUs on Sun Fire T2000, PostgreSQL cannot do the same in such cases)

* Use OLTP Type of benchmark

Where you have more than 30 simultaneous users/connections doing work on
Postgres without bottlenecking on datafiles of course :-)

* Use multiple databases or instances of Postgresql

Like migrate all your postgresql databases to one T2000. You might see
that your average response time may not be faster but it can handle
probably all your databases migrated to one T2000.

In essence, your single thread performance will not speed up on Sun Fire
T2000 but you can certainly use it to replace all your individual
postgresql servers in your organization or see higher scalability in
terms of number of users handled with 1 server with Sun Fire T2000.


For your /etc/system use the parameters as mentioned in
http://www.sun.com/servers/coolthrea...parameters.jsp

For hints on setting it up for Postgresql refer to other databases setup on
http://www.sun.com/servers/coolthrea...plications.jsp

If you get specific performance problems send email to
pgsql-performance@postgresql.org

Regards,
Jignesh





Neil Saunders wrote:

>I may be able to organize a test on a T2000 if someone could give
>advice as to an appropriate test to run...
>
>Cheers,
>
>Neil
>
>On 3/6/06, Claus Guttesen <kometen@gmail.com> wrote:
>
>
>>Hi.
>>
>>Has anybody tried the new Sun "cool-thread" servers t1000/t2000 from
>>Sun? I'd love to see benchmarks with Solaris 10 and pg 8.1.
>>
>>regards
>>Claus
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 1: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to majordomo@postgresql.org so that your
>> message can get through to the mailing list cleanly
>>
>>
>>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: explain analyze is your friend
>
>

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

pgbench according to me is more io write intensive benchmark.

T2000 with its internal drive may not perform well with pgbench with a
high load. If you are using external storage, try it out.

I havent tried it out yet but let me know what you see.


-Jignesh


Guido Neitzer wrote:

> On 06.03.2006, at 21:10 Uhr, Jignesh K. Shah wrote:
>
>> Like migrate all your postgresql databases to one T2000. You might
>> see that your average response time may not be faster but it can
>> handle probably all your databases migrated to one T2000.
>>
>> In essence, your single thread performance will not speed up on Sun
>> Fire T2000 but you can certainly use it to replace all your
>> individual postgresql servers in your organization or see higher
>> scalability in terms of number of users handled with 1 server with
>> Sun Fire T2000.
>
>
> How good is a pgbench test for evaluating things like this? I have
> used it to compare several machines, operating systems and PostgreSQL
> versions - but it was more or less just out of curiosity. The real
> evaluation was made with "real life tests" - mostly scripts which
> also tested the application server itself.
>
> But as it was it's easy to compare several machines with pgbench, I
> just did the tests and they were interesting and reflected the real
> world not as bad as I had thought from a "benchmark".
>
> So, personally I'm interested in a simple pgbench test - perhaps with
> some more ( > 50) clients simulated ...
>
> cug


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Mon, Mar 06, 2006 at 10:24:29PM +0100, Guido Neitzer wrote:
> On 06.03.2006, at 21:10 Uhr, Jignesh K. Shah wrote:
>
> >Like migrate all your postgresql databases to one T2000. You might
> >see that your average response time may not be faster but it can
> >handle probably all your databases migrated to one T2000.
> >
> >In essence, your single thread performance will not speed up on Sun
> >Fire T2000 but you can certainly use it to replace all your
> >individual postgresql servers in your organization or see higher
> >scalability in terms of number of users handled with 1 server with
> >Sun Fire T2000.
>
> How good is a pgbench test for evaluating things like this? I have
> used it to compare several machines, operating systems and PostgreSQL
> versions - but it was more or less just out of curiosity. The real
> evaluation was made with "real life tests" - mostly scripts which
> also tested the application server itself.
>
> But as it was it's easy to compare several machines with pgbench, I
> just did the tests and they were interesting and reflected the real
> world not as bad as I had thought from a "benchmark".
>
> So, personally I'm interested in a simple pgbench test - perhaps with
> some more ( > 50) clients simulated ...

I had the opportunity to do some dbt2 testing on Solaris and Sun
hardware; it's probably your best bet for a test. You'll need to
essentially fit the database into memory though, otherwise you'll be
completely I/O bound. Another issue is that currently the test framework
runs on the same machine as the database, so it's not very realistic in
that regard, but if you were to change that dependancy I'm pretty sure
OSBC would gratefully accept patches.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly