Jussi Mikkola <jussi.mikkola@bonware.com> writes:
> Yes, now I've tested with 7.2b4. The result is about the same as with 7.1.
> About 200 messages with four processors and about 600 messages with one
> processor.
That's annoying. The LWLock changes were intended to solve the
inefficiency with multiple CPUs, but it seems like we still have a
problem somewhere.
Could you recompile the backend with profiling enabled and try to get
a profile from your test case? To build a profilable backend, it's
sufficient to do
cd .../src/backendgmake cleangmake PROFILE=-pg allgmake install-bin
(assuming you are using gcc). Then restart the postmaster, and you
should notice "gmon.out" files being dropped into the various database
subdirectories anytime a backend exits. Next run your test case,
and as soon as it finishes copy the gmon.out file to a safe place.
(You'll only be able to get the profile from the last process to exit,
so try to make sure that this is representative. Might be worth
repeating the test a few times to make sure that the results don't
vary a whole lot.) Finally, do
gprof .../bin/postgres gmon.out >resultfile
to produce a legible result.
Oh, one more thing: on Linuxen you are likely to find that all the
reported routine runtimes are zero, rendering the results useless.
Apply the attached patch (for 7.2beta) to fix this.
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 */