On Mon, 2008-02-04 at 20:06 +0000, Simon Riggs wrote: > We make no attempt to limit our overall memory usage. We limit > individual sessions by default, but don't prevent them from increasing > that allocation as they choose. We don't try to reallocate memory once > it has finished being used. >
Did you read my post on LKML? Varying memory allocations are not the problem here. The problem is if you have a daemon-subprocess architecture that uses substantial amounts of shared memory. Here's another post that explains it: http://kerneltrap.org/mailarchive/linux-kernel/2007/2/12/54202 In that case (i.e. in the case of postgresql), it can count the same byte of allocated memory against the postgresql daemon (1+N/2) times, where N is the number of processes. That is plain wrong, in my opinion. PostgreSQL does not change the shared memory allocation at all during operation. Yet, even with a reasonable shared memory size that doesn't cause any memory pressure, and many *idle* connections, badness() decides (almost invariably) that the PostgreSQL daemon has more "badness" than anything else, even if a much worse process exists. On a box with 4GB of memory, badness() might plausibly think that This overcounting that punishes postgresql is the problem. Regards, Jeff Davis ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
