From: | Vitaliy Garnashevich <vgarnashevich(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: shared_buffers 8GB maximum |
Date: | 2018-02-17 06:19:31 |
Message-ID: | 2b526baa-e7a4-53d1-fa6b-f8b3f9744439@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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 trampoline so that no other
> code immediately follows it. This wastes some memory but there is
> very little added time cost.
>
>
> Spectre is about snooping within the user space of a single process -
> it has nothing to do with kernel calls. The issues with Spectre are
> things like untrusted code breaking out of "sandboxes", snooping on
> password handling or encryption, etc.
>
> Fixing Spectre requires purposefully limiting speculative execution of
> code and can significantly affect performance. But the effects are
> situation dependent.
>
I don't know the details either. But one of proposed fixes was to flush
CPU caches after doing system calls. That's the reason why I'm asking.
> So now you know that 32GB is better for your workload than 8GB. But
> that is not necessarily a reason immediately to go crazy with it. Try
> increasing it gradually - e.g., adding 16GB at a time - and see if the
> additional shared space provides any real benefit.
That's what we're going to do. Thanks!
Regards,
Vitaliy
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Tanzer | 2018-02-17 09:00:46 | Re: Any hope for more specific error message for "value too long..."? |
Previous Message | Tom Lane | 2018-02-17 05:23:25 | Re: Database health check/auditing |