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
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
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
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.
>>
>
>
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
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
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?
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
>>
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