From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: profiling pgbench |
Date: | 2010-11-24 22:34:46 |
Message-ID: | AANLkTikK=ygsba=tP_eEi75Hdc1rp21Ko8KYiG_EuUT=@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 24, 2010 at 5:33 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Wed, Nov 24, 2010 at 1:19 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> On Wednesday 24 November 2010 22:14:04 Andres Freund wrote:
>>> On Wednesday 24 November 2010 21:24:43 Robert Haas wrote:
>>>
>>> Recarding LWLockAcquire costs:
>>> Yes, its pretty noticeable - on loads of different usages. On a bunch of
>>> production machines its the second (begind XLogInsert) on some the most
>>> expensive function. Most of the time
>
>> AllocSetAlloc is the third, battling with hash_search_with_hash value. To
>> complete that sentence...
>
> I've played a bit with hash_search_with_hash_value and found that most
> of the time is spent on shared hash tables, not private ones. And the
> time attributed to it for the shared hash tables mostly seems to be
> due to the time it takes to fight cache lines away from other CPUs. I
> suspect the same thing is true of LWLockAcquire.
How do you get stats on that?
How big is a typical cache line on modern CPUs?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2010-11-24 22:38:27 | Re: profiling pgbench |
Previous Message | Jeff Janes | 2010-11-24 22:33:22 | Re: profiling pgbench |