У меня есть кластер proxmox из одного узла, и я хочу запустить новую VM с PostgreSQL и TimescaleDB, и после прочтения большого количества информации о том, как настроить тома ZFS для этой цели, у меня все еще есть некоторые сомнения относительно параметров кэша. У нас есть 3 кэша: один proxmox (ARC), один linux vm (LRU) и один PostgreSQL (clock sweep); в порядке от более удаленного к более близкому к базам данных.
Я прочитал много информации, часть из которой противоречива, поэтому я не знаю, правда ли это, но похоже, что кэш PG не спроектирован так же, как кэш ядра, где он пытается перехватить все и вытеснить только тогда, когда недостаточно места для продолжения кэширования. На самом деле, похоже, что это больше похоже на буфер для данных, которые обрабатываются в данный момент, а не на долгосрочный кэш. Действительно, это называется shared-buffers. Я думаю, именно поэтому документация не рекомендует устанавливать shared_buffers на высокий % от доступной оперативной памяти, как это делает ARC, но где-то между 25 и 50%. Похоже, что настоящий кэш PG — это кэш ядра, а не shared_buffers.
Принимая это во внимание, следует рассмотреть несколько возможных конфигураций:
- Создайте виртуальную машину с умеренным объемом оперативной памяти (допустим, 12 ГБ) и установите shared_buffers на 10 ГБ. Попытка сделать это: 1) Иметь хороший объем памяти для использования в качестве буфера для текущих запросов. 2) Запретить виртуальной машине использовать кэш, который с ее конфигурацией LRU должен быть худшим, и вместо этого использовать ARC с лучшими весами. Проблема с этой конфигурацией может заключаться в том, что кэш находится вне виртуальной машины и может снизить производительность вместо того, чтобы улучшить ее. Также не уверен, сколько места мне нужно оставить сверх размера shared_buffers, чтобы запустить ОС виртуальной машины и другие процессы базы данных.
- Создайте ВМ с большим объемом ОЗУ (допустим, 48 ГБ) и сохраните shared_buffers в тех же 10 ГБ. Также zfs устанавливает первичный кэш на метаданные. Таким образом, кэш будет ближе к БД и внутри ВМ, но с худшей логикой. Кажется, что LRU немного плохо для БД.
- Создайте ВМ с большим объемом оперативной памяти и primarycache=all. Я думаю, что это будет плохо, потому что: 1) кэши ВМ и proxmox будут конкурировать за ресурсы. 2) Дублирование кэша.
Для наглядности: узел имеет 64 ГБ общей оперативной памяти, а PG/timescaleDB будет наиболее требовательным/приоритетным приложением, работающим на нем.
Итак, верны ли мои изначальные предположения? Какая конфигурация будет работать лучше? Что бы вы изменили?
С наилучшими пожеланиями, спасибо за ваше время,
Гектор
решение1
Я рекомендую использовать Решение №4: создать ВМ с большим объемом оперативной памяти и на стороне KVM (Proxmox) использовать cache=noneдиск данных. Это остановит Proxmox от использования кэша страницы хоста вообще, эффективно выполняя реальную синхронизацию хранилища. Таким образом, вы максимально приблизитесь к голому железу в своей ВМ и сможете тонко настроить свои кэши там.
Имейте в виду, что для всех известных мне баз данных (включая PostgreSQL) буфер RAM — это не просто дисковый кэш, но и по крайней мере часть данных будет храниться в готовом для чтения формате, отличном от формата на диске. Это означает, что RAM, выделенная для процесса DB, более ценна, чем RAM, используемая только в качестве буферов ввода-вывода.
Если ваша БД может ответить на запрос из (своей) оперативной памяти, он вообще не будет проходить через стек ввода-вывода, что значительно сэкономит задержку.