Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
От | Robert Haas |
---|---|
Тема | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Дата | |
Msg-id | CA+TgmoaebRTidY=fpi70VM5nmjWp0G=UrwXq9QMbSpi-3HMg1g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile (Sergey Koposov <koposov@ast.cam.ac.uk>) |
Ответы |
Re: 9.2beta1, parallel queries, ReleasePredicateLocks,
CheckForSerializableConflictIn in the oprofile
|
Список | pgsql-hackers |
On Thu, May 31, 2012 at 7:31 AM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote: > On Wed, 30 May 2012, Robert Haas wrote: > >> I'd really like to find out exactly where all those s_lock calls are >> coming from. Is there any way you can get oprofile to output a >> partial stack backtrace? If you have perf it's very easy, just 'perf >> record -g -a <command to launch your test case>' and then 'perf report >> -g'. > > > I repeated my test with 8 threads (without tasksetting) and with > sharedbuffers=48g (because that seemed to trigger in particular long times ~ > 80 seconds). And I attach the perf report. Thanks. How did you generate this perf report? It's cool, because I haven't figured out how to make perf generate a report that is easily email-able, and it seems you have. The only trouble is that there's no call stack information here for s_lock or PinBuffer, which is what I really want. It seems to have spit out call stack information only for the kernel functions, and not for user functions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: