Re: Re: [HACKERS] high io BUT huge amount of free memory

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Миша Тюрин <tmihail(at)bk(dot)ru>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [HACKERS] high io BUT huge amount of free memory
Date: 2013-06-03 17:06:15
Message-ID: CAHyXU0zV=D5ajPgDSHky7+v8FGTy9ugpYq5w6x=h_mgtjJpvcw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 3, 2013 at 11:08 AM, Миша Тюрин <tmihail(at)bk(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-06-03 17:15:55 Re: Vacuum, Freeze and Analyze: the big picture
Previous Message Heikki Linnakangas 2013-06-03 16:22:59 Re: UTF-8 encoding problem w/ libpq