On Mon, Jun 3, 2013 at 11:08 AM, Миша Тюрин <tmih...@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_algorithm with 
> 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 shared buffers.
> I assumed if i would set smaller size of buffers that cache could work more 
> effective because files pages has more probability to 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! 16GB shared buffers => and we won 80 GB 
> of server memory! It is good result. But upto 70GB of memory are still unused 
> // instead of 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?


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to