Re: brk() function and performance

Any update on this?

---------------------------------------------------------------------------

Andrew Sullivan wrote:
> On Tue, Jul 16, 2002 at 10:28:02AM -0400, Andrew Sullivan wrote:
> > On Thu, Jul 11, 2002 at 12:30:12PM -0400, Andrew Sullivan wrote:
> > >
> > > We have noticed that one of the machines is considerably slower than
> > > the other. We have traced the problem to the brk() funciton call.
>
> More news, in case anyone is interested.
>
> It appears, after poking around the Net, that Sun ships their
> poor-performing malloc as the default on purpose, because it uses
> less memory. You can set your CFLAGS="-llibbsdmalloc" if you want to
> use the BSD library (which is on the system by default), or even just
> set LD_PRELOAD to pick up the BSD malloc instead (the latter seems to
> work just fine for the postmaster, but it breaks some other things,
> so I think I'd compile against it instead for any real work). The
> BSD malloc uses about 4 times the memory of the Solaris version, but
> it's plenty faster. Memory is cheap.
>
> Further tests, however, seem to indicate that brk() is not our main
> problem. On a test machine today, we found simple selects on a table
> with only a couple hundred rows are taking > 300 milliseconds when we
> set the shared buffers to some large number (like enough to allocate
> a Gig of memory), more than 250 ms when running with about 512 Meg of
> shared memory, but under 125 ms when running with a small shared
> buffer setting (say, enough to allocate less than 200 meg -- one test
> we allocated only 4 meg). The main culprit seems to be a memset()
> call that happens over and over to the same address. I've no idea
> why, but there it is.
>
> The same results are _not_ found in testing with 7.2.1. In that
> case, allocating a Gig of shared memory does not seem to affect the
> result at all. The only question is whether they might be if we ran
> a lot of updates agains the 7.2.x tree. (We tarred up and copied the
> data tree from production, since I had it from a recent maintenance
> period; but we had to use pg_dump to put the data into the 7.2
> database, obviously). We'll do a great whack of updates, and see if
> that makes a difference.
>
> A
>
> --
> ----
> Andrew Sullivan 87 Mowat Avenue
> Liberty RMS Toronto, Ontario Canada
> <andrew(at)libertyrms(dot)info> M6K 3E3
> +1 416 646 3304 x110
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073