Re: Memory footprint diff between 9.5 and 12

From: Tory M Blue <tmblue(at)gmail(dot)com>
To: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Memory footprint diff between 9.5 and 12
Date: 2020-05-08 20:13:27
Message-ID: CAEaSS0ZCV4tWv1=rybjgxky55BuUKMh2M9BDAbe9RgbS+_-jfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, May 7, 2020 at 11:39 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> On Thu, 2020-05-07 at 13:33 -0700, Tory M Blue wrote:
> > I hadn't noticed this until today, but a running 9.5 system with buffers
> at 10GB starts
> > and has been running years without issues. (15GB available)
> >
> > Postgres 12 will not start with that configuration, complaining about
> memory availability.
> > So Postgres12 won't start until shared buffers is 6GB, but even with
> that, my DB servers ,
> > postgres queries started complaining about being unable to allocate
> memory "unable to allocate".
> >
> > So dropping them to 4GB (on a 15GB system), may help, but did I miss a
> huge note about
> > significant memory changes between 9.5 to 12?
> >
> > Is there something else I'm missing that on busy systems is important,
> something introduced
> > in 10 or 11 as again I'm not seeing anything noted in 12.
>
> There must be something else running on the machine that allocates memory.
>
> Did you perchance run the 9.5 and the v12 server on the same machine?
>
> Yours,
> Laurenz Albe
> --
>
>
I guess the one thing I can come up with, is that my older config has
commands that are no longer valid or have been changed. or the defaults
that I'm not overwriting have changed significantly.

I'm using the stock postgresql.conf file (not edited, other than to add the
include at the bottom for my config file). the include file is our local
config and same one I've been using between 9.5 and 12, and 9.5 will start
with shared buffers of 10GB but 12 will not.

This box has 15GB of available memory.

listen_addresses = '*'
#
max_connections = 300
#
log_destination 'stderr'
#
log_directory = '/pgsql/logs'
#
logging_collector = on
#
log_filename = 'pgsql-%m-%d.log' # log file name pattern,
#
log_min_duration_statement = 80ms # -1 is disabled, 0 logs all statements
#
log_lock_waits = on # log lock waits >= deadlock_timeout
#
log_timezone = 'US/Pacific'
#
autovacuum_max_workers = 3 # max number of autovacuum subprocesses
#
autovacuum_vacuum_threshold = 10000 # min number of row updates before
#
autovacuum_analyze_threshold = 3000 # min number of row updates before
#
timezone = 'US/Pacific'
#
deadlock_timeout = 2s
#
autovacuum_work_mem = -1 # min 1MB, or -1 to use
#
max_stack_depth = 2MB # min 100kB
#
dynamic_shared_memory_type = posix # the default is the first option
#
shared_buffers = 5GB
#
effective_cache_size = 10GB
#
work_mem = 256MB
#
maintenance_work_mem = 256MB
#
# min_wal_size = 100MB
#
# max_wal_size = 2GB
#
checkpoint_completion_target = 0.9
#
wal_buffers = 16MB
#
default_statistics_target = 100
#
default_text_search_config = 'pg_catalog.simple'
#
synchronous_commit = off
#
log_line_prefix = '< %m %h >'

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2020-05-08 20:24:51 Re: pg_basebackup cannot compress to STDOUNT
Previous Message Rob Sargent 2020-05-08 19:49:07 Re: Thoughts on how to avoid a massive integer update.