Re: : bg_writer overloaded ?

Поиск
Список
Период
Сортировка
От Venkat Balaji
Тема Re: : bg_writer overloaded ?
Дата
Msg-id CAFrxt0iCV8_9EnL_QHJ6b8KrdUn3xj2RC0O9KoTzKrpHW2bYxw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: : bg_writer overloaded ?  (Scott Marlowe <scott.marlowe@gmail.com>)
Список pgsql-performance
On Wed, Nov 9, 2011 at 8:16 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Wed, Nov 9, 2011 at 2:25 AM, Venkat Balaji <venkat.balaji@verse.in> wrote:
> Hello Everyone,
> I could see the following in the production server (result of the "top" M
> command) -
>  PID    USER     PR  NI  VIRT    RES   SHR   S  %CPU   %MEM       TIME+
> COMMAND
> 25265 postgres  15   0  3329m   2.5g   1.9g   S     0.0          4.0
>  542:47.83   postgres: writer process
> The "writer process" refers to bg_writer ? and we have shared_buffers set to
> 1920 MB (around 1.9 GB).

So it is using 2.5G of mem of which 1.9G is shared memory (i.e. shared
buffers) so the actual amount of RAM it's using is ~600Megs.

I see no problem.

Is this not the indication that the shared_buffers is undersized ?
 

> In an other similar situation, we have "postgres writer process" using up 7
> - 8 GB memory constantly.

I doubt it.  Sounds more like you're misreading the output of top.

Below is the output directly taken from our production box. As per you, the writer process is taking up 1.9g from 
shared_buffers and the remaining (around 5.6 GB) from RAM.

Mem:  65980808k total, 65620700k used,   360108k free,   210792k buffers
Swap:  1052248k total,   321144k used,   731104k free, 51721468k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10306 postgres  15   0 15.7g 7.5g 1.9g S  1.9 12.0   1037:05 postgres: writer process

Is this not a problem ?
 
> pg_tune is suggesting to increase the shared_buffers to 8 GB.

Reasonable.

> If the shared_buffer is not enough, Postgres uses OS cache ?

Not really how things work.  The OS uses all spare memory as cache.
PostgreSQL uses shared_buffers as a cache.  The OS is much more
efficient about caching in dozens of gigabytes than pgsql is.

What if the shared_buffers is not enough to cache the data being read from the database ?

Thanks for your help !

Regards,
VB 

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Trying to understand Stats/Query planner issue
Следующее
От: Sergey Konoplev
Дата:
Сообщение: Re: unlogged tables