On Wed, Nov 9, 2011 at 8:16 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>wrote:
> On Wed, Nov 9, 2011 at 2:25 AM, Venkat Balaji <venkat(dot)balaji(at)verse(dot)in>
> > 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:
Is this not a problem ?
> > pg_tune is suggesting to increase the shared_buffers to 8 GB.
> > 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 !
In response to
pgsql-performance by date
|Next:||From: Sergey Konoplev||Date: 2011-11-14 08:10:47|
|Subject: Re: unlogged tables|
|Previous:||From: Tom Lane||Date: 2011-11-13 16:17:22|
|Subject: Re: Trying to understand Stats/Query planner issue |