Re: Current best practice for maximum shared_buffers settings on big hardware?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: stevenchang1213 <stevenchang1213(at)gmail(dot)com>
Cc: Bill Moran <wmoran(at)potentialtech(dot)com>, "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Current best practice for maximum shared_buffers settings on big hardware?
Date: 2017-05-24 13:27:54
Message-ID: CAFj8pRCzs5YOb6nxKhNLArehAH58Ppra9oEon8bqRdBBfCY=LQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2017-05-24 15:02 GMT+02:00 stevenchang1213 <stevenchang1213(at)gmail(dot)com>:

> hello,
> at most 40% total memory, official doc also says so.
> you can testify it using pg_prewarm and pgfincore .
>

There are strong dependency on use case. 40% total memory is related to low
memory servers .. 64GB max.

High SB requires tuning other options - like writer force

Regards

Pavel

> btw, numa supported? if so, extra care is necessary when starting db
> cluster.
>
>
>
> 從我的 Samsung Galaxy 智慧型手機傳送。
>
> -------- 原始訊息 --------
> 自: Bill Moran <wmoran(at)potentialtech(dot)com>
> 日期: 2017/5/24 20:24 (GMT+08:00)
> 至: pgsql-general(at)postgresql(dot)org
> 主旨: [GENERAL] Current best practice for maximum shared_buffers settings on
> big hardware?
>
>
> A few years ago, I was working with "big" servers. At least, they were
> big for that age, with *128G* of RAM!!!1 Holy mackeral, right?!!?
>
> Anyway, at that time, I tried allocating 64G to shared buffers and we
> had a bunch of problems with inconsistent performance, including "stall"
> periods where the database would stop responding for 2 or 3 seconds.
> After trying all sorts of tuning options that didn't help, the problem
> finally went away after reducing shared_buffers to 32G. I speculated, at
> the time, that the shared buffer code hit performance issues managing
> that much memory, but I never had the opportunity to really follow up
> on it.
>
> Now, this was back in 2012 or thereabouts. Seems like another lifetime.
> Probably PostgreSQL 9.2 at that time.
>
> Nowadays, 128G is a "medium sized" server. I just got access to one
> with 775G. It would appear that I could order from Dell with 1.5T of
> RAM if I'm willing to sell my house ...
>
> Yet, all the docs and advice I'm able to find online seem to have been
> written pre 2008 and say things like "if your server has more than 1G
> of RAM ..."
>
> I feel like it's time for a documentation update ;) But I, personally
> don't have the experience recently enough to know what sort of
> recommendations to make.
>
> What are people's experience with modern versions of Postgres on hardware
> this size? Do any of the experts have specific recommendations on large
> shared_buffers settings? Any developers care to comment on any work
> that's been done since 2012 to make large values work better?
>
> --
> Bill Moran <wmoran(at)potentialtech(dot)com>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Igor Neyman 2017-05-24 13:31:24 Re: logical replication in PG10 BETA
Previous Message Igor Neyman 2017-05-24 13:27:31 Re: logical replication in PG10 BETA