Re: Re: [HACKERS] high io BUT huge amount of free memory
От | Merlin Moncure |
---|---|
Тема | Re: Re: [HACKERS] high io BUT huge amount of free memory |
Дата | |
Msg-id | CAHyXU0zV=D5ajPgDSHky7+v8FGTy9ugpYq5w6x=h_mgtjJpvcw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] high io BUT huge amount of free memory (Миша Тюрин <tmihail@bk.ru>) |
Список | 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 по дате отправления: