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 <klep...@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.
signature.asc
Description: Digital signature
