Глава 14. Оптимизация производительности
Содержание
Быстродействие запросов зависит от многих факторов. На некоторые из них могут воздействовать пользователи, а другие являются фундаментальными особенностями системы. В этой главе приводятся полезные советы, которые помогут понять их и оптимизировать производительность Postgres Pro.
Настройка производительности должна выполняться во время разработки приложения и включать в себя точный выбор аппаратного обеспечения (например, оценку количества ЦП и памяти для каждого узла кластера Postgres Pro Shardman или настройку хранилища), настройку ОС (например, настройку параметра swappiness
или поведения, связанного с сетью) и настройку СУБД (выбор эффективной конфигурации). Но в первую очередь приложение должно быть протестировано и настроено для работы с распределённой СУБД. В такую настройку входит разработка распределённой схемы (или преобразование существующей схемы в распределённую), настройка запросов, использование пулов соединений, кеширование и даже проверка проблем с производительностью, связанных с возможными ошибками сериализации или выходом из строя узла Postgres Pro Shardman. Проектирование схемы должно включать точный выбор ключа сегментирования и выбор таблиц, которые должны стать глобальными. Обычно ключ сегментирования выбирается таким образом, чтобы:
Большинство запросов отфильтровывало большинство секций сегментированной таблицы.
Сегментированные таблицы размещались совместно, и все соединения сегментированных таблиц являлись эквивалентными соединениями по ключу сегментирования.
Эти правила позволяют Postgres Pro Shardman эффективно исключать из запросов неиспользуемые сегменты и передавать соединения для выполнения на сегменты, в которых находятся требуемые данные.
Каждый узел Postgres Pro Shardman работает как обычный сервер СУБД, поэтому все стандартные рекомендации по настройке PostgreSQL для производственной нагрузки остаются в силе. Следует выбрать значения shared_buffers
, work_mem
, efficient_cache_size
в зависимости от ресурсов, доступных для СУБД. Имейте в виду, что если для топологии кластера задано значение cross
, несколько экземпляров (указанное в Repfactor
количество) будут запущены на одном узле w
. Когда все узлы кластера подключены к сети, реплики не должны использовать много ЦП. Однако при отказе узла ведущие серверы Repfactor
групп репликации могут оказаться работающими на одном сервере, что может создать для него значительную нагрузку. При настройке параметра max_connections
обратите внимание, что каждая транзакция может инициировать n
-1 подключений, где n
— количество групп репликации в кластере. При включённом транспорте Silk, указанное выше верно и для транзакций, содержащих операции DML, а когда транспорт Silk отключён — также для транзакций только для чтения.
Другие параметры, которые, возможно, стоит настроить, — это параметры стороннего сервера. Их можно установить в разделе FDWOptions
файла конфигурации Postgres Pro Shardman. Параметры, которые существенно влияют на производительностьPostgres Pro Shardman: fetch_size, batch_size
и async_capable
. Когда транспорт Silk
отключён, fetch_size
определяет количество записей, которые одновременно извлекаются с удалённого сервера. Когда включён транспорт Silk, fetch_size
на данный момент не оказывает существенного влияния на выполнение запроса. Параметр batch_size
указывает, сколько строк можно объединить в одной удалённой операции INSERT
для сегментированной таблицы. Параметр async_capable
разрешает асинхронное выполнение и всегда должен быть включён (значение по умолчанию).
Параметр конфигурации shardman.gt_batch_size позволяет оптимизировать размер промежуточного буфера для операций INSERT
и DELETE
в глобальных таблицах.