Таблица PostgreSQL в памяти

Question

Я создал базу данных, содержащую в общей сложности 3 таблицы для определенной цели. Общий размер всех таблиц составляет около 850 МБ - очень скудный ... из которых одна отдельная таблица содержит около 800 МБ (включая индекс) данных и 5 миллионов записей (ежедневное добавление около 6000 записей).

Система PG-Windows с 8 ГБ оперативной памяти Windows 7 ноутбук с SSD. Я выделил 2048MB как shared_buffers, 256MB как temp_buffers и 128MB как work_mem. Я выполняю один запрос несколько раз против единственной таблицы - надеясь, что таблица останется в ОЗУ (отсюда приведенные выше параметры). Но, хотя я вижу всплеск в использовании памяти во время выполнения (примерно на 200 МБ), я не вижу, чтобы потребление памяти оставалось не менее 500 МБ (чтобы данные оставались в памяти). Все функции postgres exe показывают размер 2-6 МБ в диспетчере задач. Следовательно, я подозреваю, что LRU не сохраняет данные в памяти.

Среднее время выполнения запроса составляет около 2 секунд (очень простой запрос одной таблицы) ... но мне нужно довести его до 10-20 мс или даже поменьше, если это возможно, только потому, что существует слишком много раз, то же самое будет выполнено и может быть достигнуто только за счет хранения информации в памяти. Любые советы?

С уважением, Капило

Answer 1

Вы не должны ожидать postgres процессов, чтобы показать большое использование памяти, даже если вся база данных кэшируются в оперативной памяти.

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

Это означает, что, если у вас достаточно свободной памяти для всей базы данных в «свободной» операционной памяти, вы не будете стремиться попасть на диск для чтения.

В зависимости от ОС поведение при записи на диск может отличаться. Linux будет использовать «грязные» буферы с обратной записью и будет по-прежнему возвращать блоки из кеша, даже если они были записаны. Он будет записывать их обратно на диск лениво, если не будет вынужден немедленно их написать fsync(), поскольку Pg использует время COMMIT. Когда он делает это, он отмечает, что кешированные блоки чисты, но не смывают их. Я не знаю, как Windows ведет себя здесь.

Дело в том, что PostgreSQL может работать полностью из ОЗУ с базой данных 1 ГБ, хотя ни один процесс PostgreSQL не использует много оперативной памяти. Имея shared_buffers слишком высокий, просто приводит к двойному кешированию и может уменьшить объем оперативной памяти, доступный для ОС для кеш-блоков.

Непросто точно видеть, что кэшируется в ОЗУ, поскольку Pg полагается на кэш ОС. Вот почему я назвал вас pg_fincore.

Если вы работаете в Windows, и это не сработает, вам просто нужно полагаться на наблюдение за деятельностью диска. Монитор производительности показывает много незашифрованных дисков? Мониторинг памяти операционной системы показывает, сколько памяти используется для дискового кэша в ОС?

Убедитесь, что effective_cache_size правильно отражает ОЗУ, используемую для дискового кеша. Это поможет PostgreSQL выбрать соответствующие планы запросов.

Вы делаете предположение, без очевидных доказательств того, что производительность запроса, которую вы испытываете, объясняется задержками чтения диска и что ее можно улучшить с помощью кэширования в памяти. Это может быть совсем не так. Вам нужно посмотреть на показатели производительности и производительности системы explain analyze, чтобы узнать, что происходит.