Re: Query regarding postgres lock contention - Followup

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgresql(dot)org>, "Hamza Bin Sohail" <hsohail(at)purdue(dot)edu>
Subject: Re: Query regarding postgres lock contention - Followup
Date: 2011-10-05 17:48:31
Message-ID: 4E8C521F0200002500041AE3@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hamza Bin Sohail <hsohail(at)purdue(dot)edu> wrote:

> My postgres version is 8.3.7

Why such an old version? Why exclude the available bug fixes?

http://www.postgresql.org/support/versioning

>> I am aware that lock contention can be checked with lockstat (and
>> with pg_locks ? ) but I wanted to know if someone can tell me how
>> much contention there would be for this database in a 16-core
>> system vs a 4-core system. I just need a rough idea.

How many database connections will be used? If more than about
twice the number of cores, you should probably be going through a
transaction-based connection pool.

With 16 cores, even with a properly configured connection pool, you
will probably be on the edge of where spinlock contention starts
eating significant CPU time. With enough system RAM and proper
tuning the hit should be fairly minor, I think. It really gets bad
at 32 cores, although that is being improved for next year's 9.2
release.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-05 18:01:11 Re: Query regarding postgres lock contention - Followup
Previous Message Kohei KaiGai 2011-10-05 16:16:14 Re: [v9.2] DROP statement reworks