Re: brk() function and performance

Поиск
Список
Период
Сортировка
От Andrew Sullivan
Тема Re: brk() function and performance
Дата
Msg-id 20020719180255.M6252@mail.libertyrms.com
обсуждение исходный текст
Ответ на Re: brk() function and performance  (Andrew Sullivan <andrew@libertyrms.info>)
Ответы Re: brk() function and performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: brk() function and performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-general
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


В списке pgsql-general по дате отправления:

Предыдущее
От: Oliver Elphick
Дата:
Сообщение: http://developer.postgresql.org - missing pages
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: Modifying column size