Mac с / сбрасывать / очищать кэш PostgreSQL для настройки производительности

Question

Этот вопрос будет немного конкретным, потому что я перепробовал МНОГО вещей, и ничего из этого не помогло мне. Я надеюсь, что у кого-то есть другая идея.

Я работаю с PostgreSQL на Mac (ОС High Sierra) и пытаюсь повысить производительность для генерации материализованного представления, но больше не могу сравнивать мои изменения, поскольку кажется, что PostgreSQL кэшировал материализованное представление. Раньше создание материализованного представления занимало ~ 12 минут, а теперь - менее 10 секунд (тот же код, я отменил изменения).

Я использовал EXPLAIN (ANALYZE, BUFFERS), чтобы подтвердить, что почти все данные, выбираемые запросом для генерации материализованного представления, являются hit (кэшированными), а диска почти нет read s.

Я не знаю, кэшируется ли информация в общих буферах PostgreSQL или в кэше ОС, потому что в этот момент я сделал то, что, как я думал, очистило бы оба.

Вот что я пытался очистить кеш PostgreSQL:

1. Перезапустил сервер PostgreSQL, используя brew services stop postgres, а затем brew services start postgres (также пытался вызвать sync && sudo purge между ними). С помощью top и grep я подтвердил, что postgres больше не работает.
2. Используется DISCARD ALL, а также DISCARD с другими его опциями.
3. Установите для параметра shared_buffers в postgresql.conf минимальное значение (128 КБ).
4. Установлено, скомпилировано и использовано pg_dropcache .
5. Я немного посмотрел на pg_ctl, но признаюсь, что не мог понять, как его использовать. Я получил ошибку no database directory specified and environment variable PGDATA unset, и я не уверен, для чего нужно установить параметр -D / pgdata для моего случая.
6. VACUUM. Я знаю, что это не должно было сработать, но я все равно попробовал.

Вот что я пытался очистить кеш операционной системы:

1. Перезагрузка компьютера.
2. Опорожнено ~/Library/Caches и /Library/Caches.
3. sync && sudo purge, а также sync && purge.
4. Загрузился в безопасном режиме.

Я также попробовал несколько других вещей, которые, как мне показалось, заставили бы PostgreSQL сгенерировать материализованное представление с нуля (это было бы хорошо, так как сейчас мне нужно только протестировать производительность в dev):

1. Клонировал главную таблицу, использованную в материализованном представлении, и сгенерировал материализованное представление из клона. Он все еще генерируется в течение 10 секунд.
2. Зашифрованы некоторые значения столбцов (first_name, last_name, mem_id (не первичный ключ)). Он все еще генерировался в течение 10 секунд (и материализованное представление было сгенерировано правильно с вновь зашифрованными значениями).

Я застрял и больше не знаю, что попробовать. Будем благодарны за любые идеи / помощь!

Answer 1

Перезагрузка компьютера очищает оба кэша (если вы не используете что-то вроде autoprewarm из pg_prewarm, но этот код еще не выпущен). Если перезагрузка не приводит к повторному появлению проблемы, значит, вы либо исправили проблему навсегда, либо неправильно ее поняли.

Одна из возможностей состоит в том, что ANALYZE (либо ручной, либо автоматический) исправил устаревшую статистику, из-за которой плохой план использовался при обновлении материализованного представления. Другая возможность состоит в том, что VACUUM означает, что теперь сканы только по индексу больше не должны обращаться к страницам таблицы, потому что они помечены как полностью видимые. Если это так, и если по какой-то причине вы хотите воссоздать проблему, вам потребуется восстановить базу данных до состояния до запуска VACUUM или ANALYZE.

EXPLAIN (ANALYZE, BUFFERS) знает только о shared_buffers. Если что-то является попаданием только в кэш ОС, оно все равно будет сообщено как промах EXPLAIN (ANALYZE, BUFFERS). Если вы только что перезапустили PostgreSQL и при самом первом запуске запроса в основном отображается буфер hits и только несколько misses, это означает, что ваш запрос снова и снова обрабатывает одни и те же буферы. Например, это часто встречается при сканировании только по индексу, поскольку для каждой строки он обращается к одной из нескольких страниц карты видимости.