On Tue, Jun 17, 2003 at 10:45:39AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > For large allocations glibc tends to mmap() which does get unmapped. There's
> > a threshold of 4KB I think. Ofcourse, thousands of allocations for a few
> > bytes will never trigger it.
>
> But essentially all our allocation traffic goes through palloc, which
> bunches small allocations together. In typical scenarios malloc will
> only see requests of 8K or more, so we should be in good shape on this
> front.
Ah, bad news. The threshold appears to be closer to 64-128KB, so for small
allocations normal brk() calls will be made until the third or fourth
expansion. This can be tuned (mallopt()) but that's probably not too good an
idea.
On the other hand, there is a function malloc_trim().
/* Release all but __pad bytes of freed top-most memory back to the
system. Return 1 if successful, else 0. */
extern int malloc_trim __MALLOC_P ((size_t __pad));
Not entirely sure if it will help at all. Obviously memory fragmentation is
your enemy here.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> "the West won the world not by the superiority of its ideas or values or
> religion but rather by its superiority in applying organized violence.
> Westerners often forget this fact, non-Westerners never do."
> - Samuel P. Huntington