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

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL
Дата
Msg-id 20060617.111838.39487910.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Tatsuo Ishii <ishii@sraoss.co.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?

Yes. We were interested in that too. Some people did addtional tests
to determin that. I don't have the report handy now. I will report
back next week.

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

I know. I think point is 18% in s_lock only appears with 12 CPUs or more.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Exporting type OID macros in a cleaner fashion
Следующее
От: Kris Kennaway
Дата:
Сообщение: Re: postgresql and process titles