Re: Non-linear Performance

Поиск
Список
Период
Сортировка
От Curt Sampson
Тема Re: Non-linear Performance
Дата
Msg-id Pine.NEB.4.43.0205311644170.448-100000@angelic.cynic.net
обсуждение исходный текст
Ответ на Re: Non-linear Performance  (Doug Fields <dfields-pg-general@pexicom.com>)
Ответы Re: Non-linear Performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Non-linear Performance  (Doug Fields <dfields-pg-general@pexicom.com>)
Список pgsql-general
On Thu, 30 May 2002, Doug Fields wrote:

> I currently use 1.4 gigs for "shared mem" in my database (out of 2G) - I
> couldn't get PostgreSQL to run with more than that (it might be an OS
> limit, Linux 2.2).

Does it just fail to allocate? There may be a kernel parameter you
have to tweak.

I'm presuming that the idea with allocating lots of shared memory
is so that postgres can buffer data blocks from the disk. However,
since postgres uses the filesystem, the operating system will also
buffer disk data, using whatever memory is free to do so. Thus,
increaing the shared memory allocated to postgres will just reduce
the amount of memory available to the OS to do block buffering.
What is the advantage, if any, to having postgres do the buffering
in its shared memory rather than letting the OS do it?

One disadvantage I can think of is that when a back end (or several
back ends) allocates a lot of memory for sorting (assuming you let
them do that), you might end up pushing the sort memory out to your
swap disk, whereas if the OS is doing the buffer management, it
can just buffer fewer file blocks while you're doing the sort,
instead.

cjs
--
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC


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

Предыдущее
От: Cleiton Peres Reis
Дата:
Сообщение: restoring DB
Следующее
От: Curt Sampson
Дата:
Сообщение: Re: Scaling with memory & disk planning (was Re: Non-linear