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@libertyrms.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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073