Mark kirkwood <markir@slingshot.co.nz> writes:
> I will confess to being a bit of a profile newbie... so if I missed something
> important, please dont hesitate to put me right.
It looks like you profiled the postmaster (parent process), not the
backend you were interested in. I'm aware of two ways to make that
sort of mistake:
1. Backends will drop their gmon.out files into the database
subdirectory they connect to ($PGDATA/base/nnn/gmon.out).
Any gmon.out you see in the top-level directory is from the postmaster
itself or a checkpoint process --- neither of which are likely to be
interesting.
2. I dunno if Solaris has this problem, but on Linux profiling is not
inherited across fork(), so the postmaster's children fail to collect
useful data at all. There is a patch in current sources to work around
this by explicitly re-enabling the ITIMER_PROF interrupt after fork.
If this seems like the problem then try the attached (slightly old)
patch.
regards, tom lane
*** src/backend/postmaster/postmaster.c.orig Wed Dec 12 14:52:03 2001
--- src/backend/postmaster/postmaster.c Mon Dec 17 19:38:29 2001
***************
*** 1823,1828 ****
--- 1823,1829 ----
{
Backend *bn; /* for backend cleanup */
pid_t pid;
+ struct itimerval svitimer;
/*
* Compute the cancel key that will be assigned to this backend. The
***************
*** 1858,1869 ****
--- 1859,1874 ----
beos_before_backend_startup();
#endif
+ getitimer(ITIMER_PROF, &svitimer);
+
pid = fork();
if (pid == 0) /* child */
{
int status;
+ setitimer(ITIMER_PROF, &svitimer, NULL);
+
free(bn);
#ifdef __BEOS__
/* Specific beos backend startup actions */