Почему PostgreSQL не кушает больше памяти?

Question

[Ivan Palamarchuk]

Добрый день всем!

У меня инстанс специально под PostgreSQL поднят.. а он никак не хочет есть больше (всего памяти занято около 6%, это с OS).

Конфиг следующий:
max_connections = 200
shared_buffers = 2GB
effective_cache_size = 5GB
work_mem = 10MB
maintenance_work_mem = 448MB
min_wal_size = 1GB
max_wal_size = 2GB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100

RAM: 8GB

P.S.
SHOW ALL - показывает измененные данные т.е. конфиг подгружается нормально

Comments

[Roman K]

Сколько данных в таблицах? Какие индексы? Инстанс на SSD или HDD?

[Ivan Palamarchuk]

Roman Kitaev: есть одна "большая", относительно всех остальных (4кк записей), она используется для статистики и идут "прямые" записи в нее, да, в дальнейшем буду складывать в другое место, а потом раз в какой-то период выгружать эти данные в нее, но мне сейчас главное дать возможность PG разгуляться.

[Roman K]

Ivan Palamarchuk: Возможно, PG просто не может "разгуляться". Если индексов нет, то sequence read - единственный способ обработать таблицу. А для этого много памяти не надо.

[Ivan Palamarchuk]

Индексы там есть, один уникальный, второй - нет

Answer 1

[Андрей Буров]

Видимо ему больше и не надо.
Какого размера таблицы, сколько запросов, насколько сложные?
Смотрите EXPLAIN (ANALYZE,BUFFERS)
Ну и shared_buffers можно до 4-6 GB поднять.

Comments

[Ivan Palamarchuk]

В том и дело, что ей точно мало..

Простейший запрос не работающий с данными таблиц:
SELECT a::date as date FROM generate_series('2017-01-03'::date, '2017-01-11', '1 day') s(a) ORDER BY a::date DESC;

отрабатывает за 100ms.. это вообще жесть

[Ivan Palamarchuk]

А в не пиковые часы - за 30

[Ivan Palamarchuk]

shared_buffers сейчас до 4 поднял, посмотрим..

[Ivan Palamarchuk]

Сейчас проверил, тоже подтормаживают запросы, но уровень использования оперативы на прежнем уровне..

[Андрей Буров]

Ivan Palamarchuk: покажите EXPLAIN (ANALYZE,VERBOSE,BUFFERS) этого запроса (залить можно сюда https://explain.depesz.com/ )

[Ivan Palamarchuk]

Андрей Буров: https://explain.depesz.com/s/PgrY

[Андрей Буров]

Ivan Palamarchuk: посмотрите top/htop в системе, CPU точно не загружен чем-нибудь на 100%.

[Ivan Palamarchuk]

Андрей Буров: нет, 10% - postgres, все остальное меньше 1%

[Melkij]

> Простейший запрос не работающий с данными таблиц:
... не использует ни shared_buffers, ни другие ваши настройки. Только чистый work_mem - максимум памяти для одной сессии. Скромных 10мб для quicksort на 25кб более чем хватает.
Ну и с чего бы pg выделять много памяти? Хотя shared_buffers выделяются персистентно. Поэтому и вопрос к тем методам, которыми вы оцениваете потребление памяти и рестартовали ли pg после изменения объёма буфера.

Затем, где вы в указанном explain нашли 100мс? "the "actual time" values are in milliseconds of real time" https://www.postgresql.org/docs/current/static/usi...

Для проблемных запросов смотреть explain (analyze, verbose, buffers)

[Ivan Palamarchuk]

Melkij: в моем explain выгрузка в не пиковое время, когда относительно все хорошо.

[Ivan Palamarchuk]

Melkij: если show all показывает эти настройки, все же ок должно быть.. просто фишка в том, что я хочу, что бы PG тратил всю память, не могу понять почему он не тратит даже если shared_buffers 4GB..

Answer 2

[Александр Кузнецов]

Тут важный момент, что у вас за БД и как она сейчас используется.
Т.е. если используемое данную БД приложение суть простая учетная система с минимум функционала куда заходят раз в квартал - то все ок. Если приложение посложнее и пользуются им часто, и людей там не мало параллельно работает - то, скорее всего, тоже все ок, но тут я бы посоветовал поставить пива DBA, что работал с запросами и предложил бы ему продолжать в том же духе.

Comments

[Ivan Palamarchuk]

В том и фишка, что вариант - 2, спасибо