Re: Memory footprint diff between 9.5 and 12 - Mailing list pgsql-general

From Tory M Blue
Subject Re: Memory footprint diff between 9.5 and 12
Date
Msg-id CAEaSS0ZCV4tWv1=rybjgxky55BuUKMh2M9BDAbe9RgbS+_-jfA@mail.gmail.com
Whole thread Raw
In response to Re: Memory footprint diff between 9.5 and 12  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Is there a significant difference in Memory settings between 9.5 and 12  (Tory M Blue <tmblue@gmail.com>)
List pgsql-general


On Thu, May 7, 2020 at 11:39 PM Laurenz Albe <laurenz.albe@cybertec.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 >' 

pgsql-general by date:

Previous
From: Rob Sargent
Date:
Subject: Re: Thoughts on how to avoid a massive integer update.
Next
From: Adrian Klaver
Date:
Subject: Re: pg_basebackup cannot compress to STDOUNT