Re: shared_buffers 8GB maximum
От | Vitaliy Garnashevich |
---|---|
Тема | Re: shared_buffers 8GB maximum |
Дата | |
Msg-id | 2b526baa-e7a4-53d1-fa6b-f8b3f9744439@gmail.com обсуждение исходный текст |
Ответ на | Re: shared_buffers 8GB maximum (George Neuner <gneuner2@comcast.net>) |
Список | 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
В списке pgsql-general по дате отправления: