Re: 7.2 is slow?

Hi Tom!

Well, here's the profile, but yes, almost all the times are zero. Both without
the patch, and with it. Did I miss something? (Yes, I did make and install
afterwards ;-)

I made a new database, so as it was growing, the times were even slower than
before. (It would be nice, if I could create a large database from the
beginning.;)

Is this of any help? Do you need the same result with less cpus?

Jussi

Tom Lane wrote:

> Jussi Mikkola <jussi(dot)mikkola(at)bonware(dot)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/backend
> gmake clean
> gmake PROFILE=-pg all
> gmake 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 */

--
Jussi Mikkola Project Manager
Bonware Oy gsm +358 40 830 7561
Tekniikantie 12 tel +358 9 2517 5570
02150 Espoo fax +358 9 2517 5571
Finland www.bonware.com