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? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
