On Tue, Feb 09, 2010 at 08:19:51PM +0500, Anton Maksimenkov wrote:
> It means that on openbsd i386 we have about 2,2G of virtual space for
> malloc, shm*. So, postgres will use that space.
>
> But mmap() use random addresses. So when you get big chunk of memory
> for shared buffers (say, 2G) then you may get it somewhere in middle
> of virtual space (2,2G).
This is essentially the reason why it's not a good idea to use really
large amounts of shared_buffers on 32-bit systems: there isn't the
address space to support it.
> Can anybody briefly explain me how one postgres process allocate
> memory for it needs?
> I mean, what is the biggest size of malloc() it may want? How many
> such chunks? What is the average size of allocations?
There's no real maximum, as it depends on the exact usage. However, in
general postgres tries to keep below the values in work_mem and
maintainence_workmem. Most of the allocations are quite small, but
postgresql has an internal allocator which means that the system only
sees relatively large allocations. The majority will be in the order of
tens of kilobytes I suspect.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.