Re: profiling pgbench
От | Tom Lane |
---|---|
Тема | Re: profiling pgbench |
Дата | |
Msg-id | 23876.1290638982@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: profiling pgbench (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: profiling pgbench
|
Список | 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 по дате отправления: