Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL community

2006-06-17 Thread Jim Nasby

On Jun 16, 2006, at 12:01 PM, Josh Berkus wrote:
First thing as soon as I have a login, of course, is to set up a  
Buildfarm

instance.


Keep in mind that buildfarm clients and benchmarking stuff don't  
usually mix well.

--
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL community

2006-06-17 Thread Jim Nasby

On Jun 16, 2006, at 12:01 PM, Josh Berkus wrote:


Folks,

I am thrill to inform you all that Sun has just donated a fully  
loaded
T2000 system to the PostgreSQL community, and it's being setup by  
Corey

Shields at OSL (osuosl.org) and should be online probably early next
week. The system has


So this system will be hosted by Open Source Lab in Oregon.  It's  
going to

be "donated" to Software In the Public Interest, who will own for the
PostgreSQL fund.

We'll want to figure out a scheduling system to schedule  
performance and
compatibility testing on this machine; I'm not sure exactly how  
that will
work.  Suggestions welcome.  As a warning, Gavin Sherry and I have  
a bunch

of pending tests already to run.

First thing as soon as I have a login, of course, is to set up a  
Buildfarm

instance.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of  
broadcast)---

TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that  
your

   message can get through to the mailing list cleanly



--
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 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 [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL community

2006-06-16 Thread Robert Lor

Arjen van der Meijden wrote:



I can already confirm very good scalability (with our workload) on 
postgresql on that machine. We've been testing a 32thread/16G-version 
and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores 
(with all four threads enabled).


The threads are a bit less scalable, but still pretty good. Enabling 
1, 2 or 4 threads for each core yields resp 60 and 130% extra 
performance.


Wow, what type of workload is it? And did you do much tuning to get 
near-linear scalability to 32 threads?


Regards,
-Robert

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL community

2006-06-16 Thread Josh Berkus
Arjen,

> I can already confirm very good scalability (with our workload) on
> postgresql on that machine. We've been testing a 32thread/16G-version
> and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores
> (with all four threads enabled).

Keen.   We're trying to keep the linear scaling going up to 32 cores of 
course (which doesn't happen, presently).  Would you be interested in 
helping us troubleshoot some of the performance issues?

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL community

2006-06-16 Thread Arjen van der Meijden

On 16-6-2006 17:18, Robert Lor wrote:


I think this system is well suited for PG scalability testing, among 
others. We did an informal test using an internal OLTP benchmark and 
noticed that PG can scale to around 8 CPUs. Would be really cool if all 
32 virtual CPUs can be utilized!!!


I can already confirm very good scalability (with our workload) on 
postgresql on that machine. We've been testing a 32thread/16G-version 
and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores 
(with all four threads enabled).


The threads are a bit less scalable, but still pretty good. Enabling 1, 
2 or 4 threads for each core yields resp 60 and 130% extra performance.


Best regards,

Arjen

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly