Re: profiling pgbench - Mailing list pgsql-hackers

From Tom Lane
Subject Re: profiling pgbench
Date
Msg-id 23876.1290638982@sss.pgh.pa.us
Whole thread Raw
In response to Re: profiling pgbench  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: profiling pgbench
List pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> 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.

That squares with some behavior I've seen.  If you run opannotate
you often see ridiculously high time percentages attributed to extremely
trivial C statements.  The explanation seems to be that those places are
where chunks of memory are first touched, and have to be pulled into the
CPU's cache (and, if in shared memory, pulled away from some other CPU).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Remove useless whitespace at end of lines
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Remove useless whitespace at end of lines