Я проверяю некоторые настройки в своем рабочем экземпляре Postgres. Наш сервер БД имеет 32 ГБ оперативной памяти. Из pg_settings
я вижу, что effective_cache_size
установлено на:
postgres=> select name, setting, unit from pg_settings where name like 'effective_cache_size';
name | setting | unit
----------------------+---------+------
effective_cache_size | 7851762 | 8kB
(1 row)
Насколько я понимаю, это значение составляет 7851762 X 8 КБ = 62,8 ГБ. Если мои расчеты верны, мы в основном сообщаем оптимизатору, что у нас есть 62 ГБ для этого параметра, тогда как у нас есть только 32 ГБ физической оперативной памяти.
Пожалуйста, поправьте меня, если я неправильно рассчитываю этот параметр. Я всегда путаюсь с расчетом распределения параметров для модулей с 8 КБ.
7851762 умножить на 8 КБ — это примерно 60 ГБ.
Я бы установил параметр на 30 ГБ, если машина выделена для базы данных PostgreSQL.
Этот параметр сообщает PostgreSQL, сколько памяти доступно для кэширования его файлов. Если значение высокое, PostgreSQL будет оценивать соединения вложенных циклов со сканированием индекса на внутренней стороне дешевле, поскольку предполагает, что индекс, вероятно, будет кэширован.
Это никак не влияет на использование памяти PostgreSQL. Это определяется объемом памяти, доступной на вашем компьютере, параллельными процессами и настройками, такими как shared_buffers
, work_mem
и max_connections
. Все, на что влияет effective_cache_size
, это сколько памяти PostgreSQL думает доступно для кэширования. Таким образом, это влияет на предполагаемую стоимость сканирования индекса.
Насколько это может быть эффективно по скорости? можем ли мы дать Postgresql много оперативной памяти (предположим, 20% размера базы данных) и ожидать, что она будет кэшировать индексы + данные в оперативной памяти?