Как хранить базу postgres 8.4 в памяти?

Question

[Олег Петров]

Мне рассказали, что для частых однотипных запросов можно хранить всю базу в оперативной памяти.
Подскажите какая настройка позволяет это делать?
База на 200GB у меня- для меня этот способ сработает?

Answer 1

[Melkij]

Закупаете железку с 256гб ram и выше. Ставите shared_buffers в 200гб. Всё. Со временем все данные к каким обращались будут подтянуты в память. А поскольку буферов больше чем база - база их не будет вытеснять из памяти.

Можно было бы воспользоваться pg_prewarm для более удобного подтягивания данных в память после старта СУБД - да у вас какая-то ископаемая, давно уже не поддерживаемая версия. pg_prewarm для такой древности нет. (если, конечно, вы не опечатались в 9.4)
Для такого объёма shared_buffers желательно huge pages сделать по объёму на пару процентов больше чем shared_buffers. А вот как - может для 8.4 и никак, я не настолько старый DBA, не знаю.

Comments

[Олег Петров]

Да база в этом формате и перевести пока возможностей нет. =(
Как я понимаю параметра Huge pages Тоже нет у меня.
shared_buffers = 32MB Это хорошо или больше поставить?
Ram 16 GB и быстрый SSD.

[Олег Петров]

База изначально создается софтом в этом формате только.
ПОка как я понял единственный способ, который мне доступен для ускорения в моей древней базе 8.4 - это:
CREATE INDEX название ON название таблицы (название колонки);
И так сделать для каждой таблицы, которая используется в sql-Запросе после слова from и колонки после слова where.
Например если запрос. Select * from table1 where column > 0
То нужно выполнить CREATE INDEX myindex ON table1 (column);
Я все верно написал?
Прошу прощения если не точно формулирую. Просто мало опыта в этом деле, а решить задачу нужно.

[Melkij]

huge pages - это к параметрам операционной системы. До 9.2 включительно можно было извращаться с libhugetlbfs. А вот начиная с какой версии можно было извращаться - хз. Впрочем до 32гб памяти можно не заморачиваться.

shared_buffers 32мб - это кошмар. Годится только если вы на каком-нибудь утюге запустились где всего 128-256мб памяти.
Чтобы понимать масштабы - postgresql будет обрабатывать данные только в shared_buffers. Чтобы сходить за данными в индекс - надо прочитать какие-то части индекса в shared_buffers (минимум 1 страничку корня btree, дальше как получится по запросу). Чтобы по полученным из индекса ctid сходить за данными - надо идти в таблицу, читать страницы в shared_buffers. И постоянно вытеснять другие страницы из shared_buffers. Потому что в 32мб можно поместить всего 32мб/8кб = 4096 страниц. Картину немного исправляет то, что postgresql использует системный файловый кеш. Но ходить настолько интенсивно в файловый кеш штука не бесплатная.

Наша в dataegret обычная рекомендация - отдельная машина только под базу, 25% RAM под shared_buffers. Т.е. никаких приложений на той же машине - иначе невозможно контролировать ресурсы. Какой-нибудь PHP случайно откушал на 20гб памяти и база в свопе - это из реальной практики. Если база влезает в память - то можно до 75% памяти отдать под shared_buffers.

Индексы - если кратко то всё сложнее. Ненужными индексами можно сделать хуже (особенно в зависимости от интенсивности записи). Писать ещё одно сочинение по тому как проставлять индексы настроения нет. Есть замечательный материал здесь: use-the-index-luke.com

[Олег Петров]

Melkij, спасибо огромное

Answer 2

[ky0]

У постгреса есть встроенные механизмы, делающие примерно то же самое - часто используемые данные кэшируются в памяти. Всю базу хранить в памяти - несколько другое, обычно это и не требуется, при достаточном объёме выданной СУБД памяти.

Из релевантных параметров - отключение fsync (не рекомендую) и synchronous_commit.

Comments

[Melkij]

Надо учитывать, что гайки и fsync и synchronous_commit - это для операций записи. Если много читаем с медленных дисков - они никак не повлияют на происходящее.

[Олег Петров]

d 8.4 версии похоже что нет synchronous_commit. По крайней мере в Postgres.conf нет этого пункта. =(

[Олег Петров]

Melkij, Я читаю с диска ssd сотни тысяч похожих запросов с близкими параметрами.

[Melkij]

synchronous_commit в 8.4 уже был https://www.postgresql.org/docs/8.4/static/runtime...
Но перед выключением внимательно прочитайте что именно эта гайка делает. tradeoff между производительностью и риском потери последних коммитов при аварии.