Re: t1000/t2000 sun-servers

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/coolthreads/tnb/parameters.jsp

For hints on setting it up for Postgresql refer to other databases setup on
http://www.sun.com/servers/coolthreads/tnb/applications.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
>
>