Глава 14. Оптимизация производительности
Содержание
Быстродействие запросов зависит от многих факторов. На некоторые из них могут воздействовать пользователи, а другие являются фундаментальными особенностями системы. В этой главе приводятся полезные советы, которые помогут понять их и оптимизировать производительность Postgres Pro Shardman.
Настройка производительности должна выполняться во время разработки приложения и включать в себя точный выбор аппаратного обеспечения (например, оценку количества ЦП и памяти для каждого узла кластера 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 в глобальных таблицах.
Chapter 14. Performance Tips
Table of Contents
Query performance can be affected by many things. Some of these can be controlled by the user, while others are fundamental to the underlying design of the system. This chapter provides some hints about understanding and tuning Postgres Pro Shardman performance.
Performance tuning should be done during application development and include an accurate choice of hardware (for example, estimating the number of CPUs and memory per Postgres Pro Shardman cluster node or tuning your storage), OS tuning (for example, tuning the swappiness parameter or network-related behavior) and DBMS tuning (choosing efficient configuration). But first of all, an application should be tested and tuned for distributed DBMS. This includes designing a distributed schema (or converting an existing schema to a distributed one), tuning queries, using connection poolers, caching and even checking performance issues related to possible serialization errors or Postgres Pro Shardman node outage. The design of the schema should include accurate selection of a sharding key and a decision which tables should become global. Usually you select a sharding key so that:
Most of the queries filter out most of sharded table partitions.
Sharded tables are colocated and all joins of sharded tables are equi-joins on the sharding key.
These rules allow Postgres Pro Shardman to efficiently exclude unused shards from queries and to push down joins to shards where the required data resides.
Each Postgres Pro Shardman node operates as a usual DBMS server, so all standard recommendations for tuning PostgreSQL for production load remain in place. You should select shared_buffers, work_mem, effective_cache_size depending on resources available to DBMS. Keep in mind that if the cluster topology is set to cross, Repfactor instances run on a single node w. When all cluster nodes are online, replicas should not utilize a lot of CPUs. However, in case of node failure, masters for Repfactor replication groups can become running on one server, which can create significant load on it. While tuning the max_connections parameter, note that each transaction can initiate n-1 connections, where n is the number of replication groups in the cluster. When Silk is enabled, it is still true for transactions containing DML operations. When Silk is disabled, it is also true for read-only transactions.
Other parameters, which you perhaps would like to tune, are foreign server options. They can be set in FDWOptions section of Postgres Pro Shardman configuration file. Parameters that significantly affect Postgres Pro Shardman performance are fetch_size, batch_size and async_capable. When Silk transport is not enabled, fetch_size determines the number of records that are fetched from a remote server at once. When Silk transport is enabled, fetch_size currently does not have significant impact on the query execution. batch_size specifies how many rows can be combined in a single remote INSERT operation for a sharded table. async_capable allows asynchronous execution and should always be turned on (which is the default).
The shardman.gt_batch_size configuration parameter allows you to optimize the size of an intermediate buffer for INSERT and DELETE operations on global tables.
