Re: [HACKERS] Postgres Performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Postgres Performance
Дата
Msg-id 10353.936975711@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Postgres Performance  (Edwin Ramirez <ramirez@doc.mssm.edu>)
Список pgsql-hackers
Edwin Ramirez <ramirez@doc.mssm.edu> writes:
>     I believe that disk pages are 1k in linux systems, that would mean that
> I am allocating 3M when using "postmaster -i -B 3096 -o -S 2048" and 2M
> for sorting.  That is very low.  

No, buffers are 8K apiece (unless you've changed the BLCKSZ constant in
config.h).  So -B 3096 means 24 meg of buffer space.  The -S number is
indeed measured in kilobytes, however.

>     However, some of the postgres processes have memory segments larger
> than 3M (see bottom).

'top' does not show shared memory segments AFAIK, and the buffer area is
a shared memory segment.  Try "ipcs -m -a" to see what's going on in
shared memory.

> That's basically what I tried to do, but I am unable to specify a very
> large number (it complained when I tried -B > ~3900).

You're probably running into a configuration limit of your kernel ---
at a guess, your kernel is configured not to give out shared memory
segments exceeding 32Mb.

> I understand that the OS is buffering the data read from disk, but
> postgres is competing with all the other processes on the system.  I
> think that if postgres had a dedicated (user configurable) cache, like
> Oracle, then users could configure the system/postgres better.

The shared-buffer cache does serve that purpose...
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Vacuum analyze bug CAUGHT
Следующее
От: Dmitry Samersoff
Дата:
Сообщение: RE: [HACKERS] Re: Query about postgres medical database