Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows
Дата
Msg-id CABUevEzE6vWn94yct6HVmQFm9knn66kUm5p7iV_in_LopzYyKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows
Список pgsql-hackers


On Sat, Nov 12, 2016 at 4:03 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Fri, Nov 11, 2016 at 3:01 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> > Based on this optimization we might want to keep the text that says
>> > large
>> > shared buffers on Windows aren't as effective perhaps,

Sounds sensible or may add a line to say why it isn't as effective as on Linux.

Do we actually know *why*?

 
> and just remove
>> > the
>> > sentence that explicitly says don't go over 512MB?
>>

Have we done any windows specific optimization since it was originally
mentioned as 512MB which indicates that we can remove it?  Are you
telling it based on results in this thread, if so, I think it is
better to do few more tests before changing it.

Well, that advice goes *way* back. Many things have changed since then - and just look at things like the updating of the stats target. For one thing, we're in 64-bit now, not 32, for the majority of users. We reserve the shared memory on startup which was done for address probability issues, but may have had side effects. And *Windows itself* has changed in those 10 or so years.

I've heard it from other people as well, but this thread is definitely one of them. I think the old truth about "never go above that" is invalid at this point, but it may never have been valid. But I also don't think we know what to put there instead, as a recommendation.

 
>> Just removing the reference to the size would make users ask a question
>> "What size is the effective upper limit?"
>
>
> True, but that's a question for other platforms as well, isn't it?
>

Right, but for other platforms, the recommendation seems to be 25% of
RAM, can we safely say that for Windows as well?  As per test results
in this thread, it seems the read-write performance degrades when
shared buffers have increased from 12.5 to 25%.  I think as the test
is done for a short duration so that degradation could be just a run
to run to run variation, that's why I suggested doing few more tests.

We talk about 25%, but only up to a certain size. It's suggested as a starting point. The 25% value us probably good as a starting point, as it's recommended, but not as a "recommended setting". I'm fine with doing something similar for Windows -- say "10-15% as a starting point, but you have to check with your workload" kind of statements.
 
--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Indirect indexes
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Do we need use more meaningful variables to replace 0 in catalog head files?