Skip site navigation (1) Skip section navigation (2)

Re: Sun Donated a Sun Fire T2000 to the PostgreSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: Robert(dot)Lor(at)Sun(dot)COM, pgsql-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
Date: 2006-06-17 02:34:15
Message-ID: 10226.1150511655@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> writes:
> Interesting. We (some Japanese companies including SRA OSS,
> Inc. Japan) did some PG scalability testing using a Unisys's big 16
> (physical) CPU machine and found PG scales up to 8 CPUs. However
> beyond 8 CPU PG does not scale anymore. The result can be viewed at
> "OSS iPedia" web site (http://ossipedia.ipa.go.jp). Our conclusion was
> PG has a serious lock contention problem in the environment by
> analyzing the oprofile result.

18% in s_lock is definitely bad :-(.  Were you able to determine which
LWLock(s) are accounting for the contention?

The test case seems to be spending a remarkable amount of time in LIKE
comparisons, too.  That probably is not a representative condition.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Robert LorDate: 2006-06-17 04:17:04
Subject: Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community
Previous:From: Tatsuo IshiiDate: 2006-06-17 02:18:38
Subject: Re: Sun Donated a Sun Fire T2000 to the PostgreSQL

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-06-17 02:58:05
Subject: Exporting type OID macros in a cleaner fashion
Previous:From: Tom LaneDate: 2006-06-17 02:26:27
Subject: Re: Curious bug in buildfarm files-changed links

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group