Re: Re: [HACKERS] high io BUT huge amount of free memory - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Re: [HACKERS] high io BUT huge amount of free memory
Date
Msg-id CAHyXU0zV=D5ajPgDSHky7+v8FGTy9ugpYq5w6x=h_mgtjJpvcw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] high io BUT huge amount of free memory  (Миша Тюрин <tmihail@bk.ru>)
List pgsql-hackers
On Mon, Jun 3, 2013 at 11:08 AM, Миша Тюрин <tmihail@bk.ru> wrote:
> Hi all hackers again!
> Since i had got this topic there many test was done by our team and many papers was seen. And then I noticed that
os_page_replacement_algorithmwith CLOCK and others features 
>
> might * interfere / overlap * with/on postgres_shared_buffers.
>
> I also think there are positive correlation between the write load and the pressure on file cache in case with large
sharedbuffers. 
>
> I assumed if i would set smaller size of buffers that cache could work more effective because files pages has more
probabilityto be placed in the right place in memory. 
>
> After all we set shared buffers down to 16GB ( instead of 64GB ) and we got new pictures. Now we have alive raid!
16GBshared buffers => and we won 80 GB of server memory! It is good result. But upto 70GB of memory are still unused //
insteadof 150. In future I think we can set shared buffers more close to zero or to 100% of all available memory. 
>
> Many thanks Oleg Bartunov and Fedor Sigaev for their tests and some interesting assumptions.

hm, in that case, wouldn't adding 48gb of physical memory have
approximately the same effect?  or is something else going on?

merlin



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: UTF-8 encoding problem w/ libpq
Next
From: Josh Berkus
Date:
Subject: Re: Vacuum, Freeze and Analyze: the big picture