Re: shared_buffers 8GB maximum

2018-02-19 Thread Vitaliy Garnashevich
When we did calculation of some analytic tasks, then increasing shared_buffers had negative impact on speed. Probably hit ration was too low after change, but the maintenance of shared buffers (searching free blocks) was slower. What was the size of shared buffers when slowdown happened

Re: shared_buffers 8GB maximum

2018-02-19 Thread Vitaliy Garnashevich
Yes.  I don't know the exact reason, but reading a buffer from OS cache is quite a bit more expensive than just pinning a buffer already in the buffer_pool, about 5 times more expensive the last time I tested it, which was before Meltdown.  (And just pinning a buffer which is already in the

Re: shared_buffers 8GB maximum

2018-02-18 Thread Tomas Vondra
On 02/18/2018 02:41 PM, Vitaliy Garnashevich wrote: > >> I certainly wouldn't recommend using 1/2 of RAM right away. There's >> a good chance it would be a waste of memory - for example due to >> double buffering, which effectively reduces "total" cache hit >> ratio. > > Double buffering is

Re: shared_buffers 8GB maximum

2018-02-18 Thread Pavel Stehule
2018-02-18 14:41 GMT+01:00 Vitaliy Garnashevich : > > I certainly wouldn't recommend using 1/2 of RAM right away. There's a >> good chance it would be a waste of memory - for example due to double >> buffering, which effectively reduces "total" cache hit ratio. >> > >

Re: shared_buffers 8GB maximum

2018-02-18 Thread Vitaliy Garnashevich
I certainly wouldn't recommend using 1/2 of RAM right away. There's a good chance it would be a waste of memory - for example due to double buffering, which effectively reduces "total" cache hit ratio. Double buffering is often mentioned in context of tuning shared buffers. Is there a tool

Re: shared_buffers 8GB maximum

2018-02-16 Thread Vitaliy Garnashevich
Not necessarily - it depends on exactly what was changed ... which unfortunately I don't know for certain. Any filesystem call is a kernel transition. That's a Meltdown issue. Meltdown can be avoided by using trampoline functions to call the (real) kernel functions and isolating each

Re: shared_buffers 8GB maximum

2018-02-16 Thread Jeff Janes
On Fri, Feb 16, 2018 at 2:36 PM, Vitaliy Garnashevich < vgarnashev...@gmail.com> wrote: > Hi All, > > I've seen the shared_buffers 8GB maximum recommendation repeated many > times. I have several questions in this regard. > > - Is this recommendation still true for recent versions of postgres?

Re: shared_buffers 8GB maximum

2018-02-16 Thread Tomas Vondra
On 02/17/2018 02:56 AM, George Neuner wrote: > On Sat, 17 Feb 2018 00:36:57 +0200, Vitaliy Garnashevich > wrote: > ... > >> Could that be a reason for increasing the value of shared_buffers? >> >> - Could shared_buffers=128GB or more on a 250 GB RAM server be a >>

Re: shared_buffers 8GB maximum

2018-02-16 Thread George Neuner
On Sat, 17 Feb 2018 00:36:57 +0200, Vitaliy Garnashevich wrote: >- I'm not a huge Linux expert, but I've heard someone saying that >reading from the filesystem cache requires a context switch. Yes. >I suspect >that such reads are slightly more expensive now after