Вертикално мащабиране на PostgreSQL

PostgreSQL може да мащабира доста добре вертикално. Колкото повече ресурси (CPU, памет, диск) можете да предоставите на вашия PostgreSQL сървър, толкова по-добре може да работи. Въпреки това, докато някои части на Postgres могат автоматично да използват увеличените ресурси, други части се нуждаят от промени в конфигурацията, преди да могат да бъдат забелязани подобренията.

Прочетете, за да научите повече за това как да гарантирате, че PostgreSQL използва пълноценно системата, в която го използвате.

ЦП

Какво се мащабира автоматично

PostgreSQL има традиционна архитектура на процесите, състояща се от главен процес (наречен postmaster ), който поражда нов процес (нареченbackend ) за всяка нова клиентска връзка. Това означава, че ако има повече налични ядра на процесора, повече процеси могат да се изпълняват едновременно и следователно бекендовете не трябва да се борят толкова много за наличността на процесора. Заявките, свързани с процесора, ще завършат по-бързо.

Може да искате да коригирате максимално разрешените едновременни връзки на ниво система, база данни или потребител:

-- system level
ALTER SYSTEM SET max_connections = 200;

-- database level
ALTER DATABASE dbname CONNECTION LIMIT 200;

-- user level
ALTER ROLE username CONNECTION LIMIT 20;

така че измамните приложения да не могат да задържат твърде много връзки.

Какво се нуждае от настройка

Сървърът на PostgreSQL може да създаде процес, който да се грижи за домашни задачи, като вакуумиране, репликация, абонаменти (за логическа репликация) и т.н. Броят на тези работници не се определя динамично, а просто се задава чрез конфигурация и е по подразбиране 8.

Конфигурационната настройка от най-високо ниво за броя работни процеси е:

# typically specified in postgresql.conf
max_worker_processes = 16

Увеличаването на тази стойност може водят до ускоряване на задачи за поддръжка, паралелни заявки и създаване на индекс.

Паралелни заявки

Започвайки с версия 9.6, Postgres може да изпълнява заявки паралелно, ако плановникът на заявки реши, че ще помогне. Паралелното запитване включва пораждане на работници, разпределяне на работата между тях и след това събиране (събиране) на резултатите. При спазване на общото ограничение на max_worker_processes зададен по-рано, Postgres ще определи колко работници могат да бъдат създадени за паралелна заявка в зависимост от стойността на две конфигурационни настройки:

# the maximum number of workers that the system can
# support for parallel operations
max_parallel_workers = 8

# the maximum number of workers that can be started
# by a single Gather or Gather Merge node
max_parallel_workers_per_gather = 8

Ако имате неактивни процесори и паралелизирани заявки, увеличаването на тези стойности може да ускори такива заявки.

Създаване на паралелен индекс

В Postgres 11 беше добавена поддръжка за паралелно създаване на B-Tree индекси. Ако редовно създавате B-Tree индекси или ги REINDEX, увеличаването на тази стойност може да помогне:

# the maximum number of parallel workers that can be
# started by a single utility command
max_parallel_maintenance_workers = 8

Това ще позволи на Postgres да създаде тези много работници (в зависимост от общия лимит от max_worker_processes ), за да се ускори създаването на B-Tree индекси.

Логическа репликация

Логическата репликация (достъпна в Postgres 10 и по-нова версия) разчита на работни процеси от страната на абонамента, за да извлече промени от издателя. Като зададете Postgres за създаване на повече работници за логична репликация, промените могат да бъдат извлечени и приложени паралелно, особено ако има повече таблици. Тази настройка за конфигурация увеличава общия брой работници за репликация:

# maximum number of logical replication workers
max_logical_replication_workers = 8

При поточно репликация можете да започнете синхронизиране с базов архив. За логическа репликация обаче промените трябва да бъдат изтеглени чрез самия протокол за репликация през мрежата. Това може да отнеме време. Разрешаването на повече работници по време на фазата на синхронизиране може да ускори този процес:

# basically the number of tables that are synced in
# parallel during initialization of subscription
max_sync_workers_per_subscription = 8

Автоматично вакуумиране

Периодично, въз основа на куп конфигурационни настройки, Postgres ще пуска множество работници, които ще ПРАСХОСЯТ таблиците на базата данни. Това, разбира се, се нарича автовакуум и броят на работниците, които автоматичното вакуумно стартиране създава всеки път, може да бъде зададен чрез настройката за конфигурация:

# the maximum number of autovacuum processes
autovacuum_max_workers = 8

Компресия на WAL

Ако имате свободен процесор, можете да обменяте CPU за честотна лента на диска, като компресирате страниците, които са записани във файловете WAL. Това намалява количеството данни, които трябва да бъдат записани на диска, за сметка на повече цикли на процесора за компресиране на данните. Той също така намалява размера на данните, които трябва да бъдат изпратени по кабела за стрийминг репликация.

На практика ползите от WAL компресията си заслужават много разумните разходи. За да го включите, използвайте:

# compresses full page images written to WAL
wal_compression = on

Памет

Какво се мащабира автоматично

Операционната система автоматично управлява и използва памет, която не се използва от никое приложение за кеширане на данни, прочетени и записани на диска наскоро. Това значително ускорява дисково-интензивните приложения и със сигурност PostgreSQL.

В Linux, най-популярният хост за Postgres, размерът на кеша на диска на ОС не може да бъде зададен от потребителя. Управлението му е вътрешно за Linux. При натиск на паметта това ще даде дискова кеш памет на приложенията.

Какво се нуждае от настройка

Планиране на заявки

Инструментът за планиране на заявки трябва да включи количеството дисков кеш, предоставен от ОС като фактор в своите оценки. Ако сте успели да увеличите значително дисковия кеш на операционната система (чрез увеличаване на наличната памет), увеличаването на тази настройка за конфигурация може да помогне за подобряване на прогнозите на планировщика:

# the planner's assumption about the effective size
# of the disk cache that is available to a single query.
effective_cache_size = 64GB

Споделена памет

PostgreSQL използва набор от буфери, които се споделят между всички работници и backendprocesses. Те се наричат ​​споделени буфери , а количеството памет, разпределена за споделени буфери, се задава с помощта на конфигурационната настройка:

shared_buffers = 32GB

Временни буфери

Когато се осъществява достъп до временни таблици чрез заявка, буферите се разпределят за кеширане на съдържанието, което се чете. Размерът на този буфер се задава с помощта на настройката за конфигурация:

# the maximum number of temporary buffers used
# by each database session
temp_buffers = 100MB

Ако имате свободна памет и заявки, които използват силно временни таблици, увеличаването на тази стойност може да ускори такива заявки.

Работна памет

Работната памет се разпределя локално и частно от бекенда. Използва се за извършване на сортиране и обединяване, без да се налага да се създава във временни таблици. Увеличаването на това от 4MB по подразбиране може да позволи на заявките да завършват по-бързо чрез създаване на временна таблица:

# the amount of memory to be used by internal sort
# operations and hash tables before writing to temporary disk files
work_mem = 16MB

Операции по поддръжка

Паметта, използвана от VACUUM, създаване на индекс и други подобни команди за поддръжка, се контролират от конфигурационната настройка maintenance_work_mem . Увеличаването на тази сума може да ускори тези операции, особено върху индекси или таблици, които трябва да бъдат пресъздадени.

Паметта, използвана от работещите в автовакуум, може да бъде взета от паметта за поддръжка (чрез задаване на autovacuum_work_mem = -1 ) или конфигурирани независимо.

# the maximum amount of memory to be used by
# maintenance operations
maintenance_work_mem = 128MB

# maximum amount of memory to be used by each
# autovacuum worker process
autovacuum_work_mem = -1

Диск

Какво се мащабира автоматично

Дисковете могат да бъдат направени по-големи, по-бързи или по-едновременни. Размерът на диска е единственото нещо, за което PostgreSQL не трябва да се инструктира. По подразбиране PostgreSQL няма да се ограничава от използването на налично дисково пространство. Обикновено това е добре.

Можете обаче да поставите ограничение за общия размер на създадените временни файлове, за да осигурите известна степен на защита срещу заявки, които се опитват да сортират милиард редове и други подобни:

# the maximum amount of disk space that a process
# can use for temporary files
temp_file_limit = 500GB

Какво се нуждае от настройка

Контролентност

RAID дискове и файлови системи като ZFS могат да бъдат настроени да поддържат повече паралелност. Това означава, че можете да имате няколко четения/записвания на диск, които се обслужват едновременно от такива файлови системи поради начина, по който съхраняват или обработват данните вътрешно.

Можете да позволите на Postgres да издава множество едновременни I/O дискове, като използвате тази настройка за конфигурация:

# the number of concurrent disk I/O operations that
# PostgreSQL expects can be executed simultaneously
effective_io_concurrency = 4

В момента обаче това се използва само при сканиране на растерни карти.

Случайна цена на страницата

Инструментът за планиране на заявки на Postgres приема, че последователното четене е по-бързо от произволното четене. Точно колко по-бърза е стойност, която можете да настроите. По подразбиране предполага, че произволните четения са 4 пъти по-скъпи.

В зависимост от настройката на вашия диск, работното натоварване и сравнителния анализ, ако сте сигурни, че произволните четения са само два пъти по-скъпи от последователните, можете да кажете това на Postgres:

# the planner's estimate of the cost of a disk page
# fetch that is part of a series of sequential fetches
seq_page_cost = 1

# the planner's estimate of the cost of a
# non-sequentially-fetched disk page
random_page_cost = 2

Пространства за таблици

За да се възползвате от множество дискове, които не са монтирани като една голяма единична файлова система, можете да използвате пространства за таблици. С пространствата за таблици можете да поставяте таблици или да индексирате различни файлови системи. Това може да подобри едновременността и осигурява лесен начин за справяне с растежа на таблицата.

CREATE TABLESPACE disk2 LOCATION '/mnt/disk2/postgres';

Прочетете повече за пространствата за таблици тук.

Мрежа

Мрежата обикновено е най-малко използвания ресурс на PostgreSQL сървър и рядко е наситен. Ако имате нужда от мащабиране, достатъчно е лесно да добавите още мрежови интерфейси, всеки със собствен IP и да накарате PostreSQL да ги слуша всички:

listen_addresses = '10.1.0.10,10.1.0.11'

Клиентите ще трябва да бъдат балансирани на натоварването във всички IP адреси, на които Postgresliens.

Друго

Има няколко други настройки за конфигурация, които могат да бъдат коригирани, повечето от които използват повече CPU и памет.

Дялови операции

Postgres 10 въведе разделяне на таблици, което беше подобрено в Postgres 11. Някои оптимизации на заявки за дялове не са включени по подразбиране, тъй като могат да доведат до по-висока консумация на процесор и памет. Това са:

# allow a join between partitioned tables to be
# performed by joining the matching partitions
enable_partitionwise_join = on

# allow grouping or aggregation on a partitioned
# tables performed separately for each partition
enable_partitionwise_aggregate = on