Re: profiling pgbench
От | Andres Freund |
---|---|
Тема | Re: profiling pgbench |
Дата | |
Msg-id | 201011242338.27584.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: profiling pgbench (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wednesday 24 November 2010 23:34:46 Robert Haas wrote: > On Wed, Nov 24, 2010 at 5:33 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > > On Wed, Nov 24, 2010 at 1:19 PM, Andres Freund <andres@anarazel.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? Btw, if you have some recent kernel I would try to use perf - I find the event mappings easier to understand there, but maybe thats just me jumping onto bandwagons. > How big is a typical cache line on modern CPUs? for the line size cat /sys/devices/system/cpu/cpu0/cache/index*/coherency_line_size for the overall size cat /sys/devices/system/cpu/cpu0/cache/index*/size Andres
В списке pgsql-hackers по дате отправления: