Re: Memory footprint diff between 9.5 and 12

Поиск
Список
Период
Сортировка
От Tory M Blue
Тема Re: Memory footprint diff between 9.5 and 12
Дата
Msg-id CAEaSS0ZCV4tWv1=rybjgxky55BuUKMh2M9BDAbe9RgbS+_-jfA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Memory footprint diff between 9.5 and 12  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Is there a significant difference in Memory settings between 9.5 and 12
Список 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 по дате отправления:

Предыдущее
От: Rob Sargent
Дата:
Сообщение: Re: Thoughts on how to avoid a massive integer update.
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: pg_basebackup cannot compress to STDOUNT