Postgresql производительность кеша (памяти) + как прогреть кеш - PullRequest
11 голосов
/ 01 июня 2009

У меня есть таблица БД с 25M строками, ~ 3 КБ каждая (т.е. ~ 75 ГБ), которые вместе с несколькими используемыми индексами (дополнительные 15-20 ГБ) не умещаются полностью в памяти (64 ГБ на машине). Типичный запрос находит 300 строк через индекс, опционально фильтрует их до ~ 50-300 строк, используя другие индексы, и, наконец, извлекает соответствующие строки. Время отклика варьируется от 20 мс на теплой БД до 20 с на холодной БД. У меня есть два связанных вопроса:

  1. В какой момент времени я могу проверить, какая часть (%) определенных таблиц и индексов кэшируется в памяти?

  2. Как лучше прогреть кеш перед открытием БД для запросов? Например. «select *» запускает последовательное сканирование (~ 15 минут на холодной базе данных), но время отклика после него все еще невелико. Есть ли встроенный способ сделать это вместо запросов? A

Спасибо, не стесняйтесь ответить также по электронной почте (info@shauldar.com])

- Шауль

Ответы [ 4 ]

5 голосов
/ 02 июня 2009

Что касается вашего первого пункта, модуль contrib "pg_buffercache" позволяет вам проверять содержимое буферного кеша. Мне нравится определять это:

create or replace view util.buffercache_hogs as
select case
       when pg_buffercache.reldatabase = 0
            then '- global'
       when pg_buffercache.reldatabase <> (select pg_database.oid from pg_database where pg_database.datname = current_database())
            then '- database ' || quote_literal(pg_database.datname)
       when pg_namespace.nspname = 'pg_catalog'
            then '- system catalogues'
       when pg_class.oid is null and pg_buffercache.relfilenode > 0
            then '- unknown file ' || pg_buffercache.relfilenode
       when pg_namespace.nspname = 'pg_toast' and pg_class.relname ~ '^pg_toast_[0-9]+$'
            then (substring(pg_class.relname, 10)::oid)::regclass || ' TOAST'::text
       when pg_namespace.nspname = 'pg_toast' and pg_class.relname ~ '^pg_toast_[0-9]+_index$'
            then ((rtrim(substring(pg_class.relname, 10), '_index'))::oid)::regclass || ' TOAST index'
       else pg_class.oid::regclass::text
       end as key,
       count(*) as buffers, sum(case when pg_buffercache.isdirty then 1 else 0 end) as dirty_buffers,
       round(count(*) / (SELECT pg_settings.setting FROM pg_settings WHERE pg_settings.name = 'shared_buffers')::numeric, 4) as hog_factor
from pg_buffercache
     left join pg_database on pg_database.oid = pg_buffercache.reldatabase
     left join pg_class on pg_class.relfilenode = pg_buffercache.relfilenode
     left join pg_namespace on pg_namespace.oid = pg_class.relnamespace
group by 1
order by 2 desc;

Кроме того, модуль contrib "pageinspect" позволяет вам получить доступ к определенной странице из отношения, поэтому я полагаю, что вы можете просто просмотреть все страницы в отношении, захватывая их?

select count(get_raw_page('information_schema.sql_features', n))
from generate_series(0,
        (select relpages-1 from pg_class where relname = 'sql_features')) n;

Это загрузит все information_schema.sql_features в кеш.

2 голосов
/ 01 июня 2009

2) Обычно я решаю эту проблему, регистрируя запросы из действующей системы и воспроизводя их. Это согревает типичные части данных, а не части, которые используются не так часто (что в противном случае привело бы к потере оперативной памяти).

1 голос
/ 01 июня 2009

Ad. 1 - у меня нет абсолютно никакой идеи.

Ad. 2 - почему бы вам не выбрать случайным образом некоторые важные запросы и запустить их на холодном сервере? чем больше запросов вы будете выполнять, тем лучше будет процесс прогрева.

0 голосов
/ 15 мая 2012

Не пытайтесь прогреть память, это работает postgresql и ОС. Просто разделите таблицы (и индексы) на разделы и попробуйте работать с меньшими наборами данных. Если вам удастся создать хороший план разбиения, то проблем с огромными индексами или таблицами не возникнет. Если вы все еще хотите прогреть таблицы и индексы, возможно, их можно полностью кэшировать в ОЗУ, поскольку они меньше, чем раньше.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...