Re: Controlling memory of session

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Controlling memory of session
Дата
Msg-id 9406.1169046360@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Controlling memory of session  (Richard Huxton <dev@archonet.com>)
Список pgsql-general
Richard Huxton <dev@archonet.com> writes:
> James Im wrote:
>> What am I missing to limit the memory taken by session to 1MB?

> You can't. In particular, work_mem is memory *per sort* so can be
> several times that. If you're trying to get PG to run in 64MB or
> something like that, I think you're going to be disappointed.

Yeah.  I think the working RAM per backend is approaching a megabyte
these days just for behind-the-scenes overhead (catalog caches and
so forth), before you expend even one byte on per-query structures
that work_mem would affect.

Something else to consider: I dunno what tool you were using on Windows
to look at memory usage or how it counts shared memory, but on Unix a
lot of process-monitoring tools tend to count shared memory against each
process touching that shared memory.  Which leads to artificially
bloated numbers.  The default PG shared memory block size these days is
order-of-10-megabytes I think; if a backend has touched any significant
fraction of that since it started, that could dwarf the backend's true
private workspace size.

If you're concerned about total memory footprint for a pile of backends,
usually the right answer is to put some connection-pooling software in
front of them, not try to hobble each backend to work in a tiny amount
of space.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: The jdbc and current_timestamp
Следующее
От: "Jeremy Haile"
Дата:
Сообщение: Diagnosing deadlock / connection hang