From: | Craig James <craig_james(at)emolecules(dot)com> |
---|---|
To: | Pierre Frédéric Caillaud <lists(at)peufeu(dot)com> |
Cc: | Reydan Cankur <reydan(dot)cankur(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Using Gprof with Postgresql |
Date: | 2009-09-08 14:30:12 |
Message-ID: | 4AA66A74.7030408@emolecules.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Pierre Frédéric Caillaud wrote:
>> I just compiled it with gcc and produces the gmon.out file for every
>> process; by the way I am running below script in order to produce
>> readable .out files
>>
>> gprof .../pgsql/bin/postgres gmon.out > createtable2.out
>>
>> is postgres the right executable?
>>
>> regards
>> reydan
>
> Off topic, but hace you tried oprofile ? It's excellent...
I find valgrind to be an excellent profiling tool. It has the advantage that it runs on an unmodified executable (using a virtual machine). You can compile postgres the regular way, start the system up, and then create a short shell script called "postgres" that you put in place of the original executable that invokes valgrind on the original executable. Then when postgres starts up your backend, you have just one valgrind process running, rather than the whole Postgres system.
Valgrind does 100% tracing of the program rather than statistical sampling, and since it runs in a pure virtual machine, it can detect almost all memory corruption and leaks.
The big disadvantage of valgrind is that it slows the process WAY down, like by a factor of 5-10 on CPU. For a pure CPU process, it doesn't screw up your stats, but if a process is mixed CPU and I/O, the CPU will appear to dominate.
Craig
From | Date | Subject | |
---|---|---|---|
Next Message | Grzegorz Jaśkiewicz | 2009-09-08 15:33:04 | Re: Forcing postgresql to use an index |
Previous Message | Eugene Morozov | 2009-09-08 14:12:21 | Forcing postgresql to use an index |