Re: brk() function and performance

From: Gregory Seidman <gss+pg(at)cs(dot)brown(dot)edu>
To: PostgreSQL general list <pgsql-general(at)postgresql(dot)org>
Cc: Andrew Sullivan <andrew(at)libertyrms(dot)info>
Subject: Re: brk() function and performance
Date: 2002-07-16 16:50:39
Message-ID: 20020716165039.GE10022@cs.brown.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andrew Sullivan sez:
} 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.
}
} My Sun-loving colleague, Sorin Iszlai, wondered why this problem was
} cropping up, and remembered the qsort() debacle. So he did some
} tests. Guess what? Here's what he found:
}
} > I ran some tests with the realloc() function from the standard lib;
} > If the application calls realloc() 4096 times the results are:
}
} > - if linked with bsdmalloc, realloc() calls brk() 17 times only:
} > syscall seconds calls
} > brk .40 17
}
} > - and without bsdmalloc :
} > syscall seconds calls
} > brk 1.36 24527
}
} At this rate, I'm beginning to get the feeling that maybe getting
} FreeBSD to work well on 64 bit Sun machines is the most important
} project we could undertake ;-)
}
} Anyway, I'm going to do some tests with this, but in the meantime, if
} anyone has any views on the subject, insights, or experience, it'd be
} much appreciated.

Way back when I was a college freshman or sophomore, I was talking to a
professor who mentioned having had tremendous problems with the brk()
system call robbing him of system performance. His solution, since brk() is
called when malloc decides it needs another page or so, was to allocate a
*tremendous* amount of memory at the very beginning of his run, then free
it all. This meant that Solaris mapped a whole bunch of pages to his app
with just one brk() call, and once it was released it was in malloc's free
list. The pages weren't swapped/paged or anything because until they were
written to or read from, they didn't even really exist except in the OS's
internal tables. It just took the OS out of the loop in memory allocation.

This may ar may not be a good solution. I would expect it to fail or have
bad performance characteristics on at least some flavors of Unix, and
probably Windows. Still, it might be worth looking into on Solaris.

} Thanks.
} A
--Greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-07-16 16:54:18 Re: integer out of range errors
Previous Message Stephan Szabo 2002-07-16 16:32:08 Re: Disabling case sensitivity