Основно наблюдение на PostgreSQL – част 1

Какви показатели за внедряването на PostgreSQL трябва да наблюдавате? Тази серия от публикации в блога има за цел да предостави минимален, начален набор от основни действия за наблюдение, които трябва да приложите, за да гарантирате здравето и стабилността на вашите Postgres сървъри.

Първата част обхваща параметрите на ниво клъстер.

Част 1:Ниво на клъстер

На жаргон на Postgres, клъстер е набор от бази данни, управлявани от един екземпляр на сървър Postgres. Функции като репликация и WAL архивиране работят на ниво клъстер.

1. Диапазон на идентификатора на транзакция

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

Всяка транзакция има уникален 32-битов целочислен идентификатор, нареченидентификатор на транзакцията . По различни причини разликата между идентификатора на първата и последната транзакция трябва да е по-малко от 2, което е около 2 милиарда. Поддържането на диапазона доста под тази граница е задължително – прочетете тази реална история за това, което се случва иначе.

Действие:Непрекъснато следете диапазона на идентификационните номера на транзакцията, предупреждавайте, ако стойността надвиши зададен праг.

Как да:

-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
       regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
  FROM pg_control_checkpoint();

-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
  FROM pg_database;

2. Брой бекендове

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

Действие:Следете максималния брой бекенд през всеки ден/седмица, проучвайте нарастващите тенденции.

Как да:

-- returns the count of currently running backends
SELECT count(*)
  FROM pg_stat_activity;

3. Неактивни слотове за репликация

Слотовете за репликация са маркирани като „неактивни“, когато клиентът за репликация, свързан към слота, прекъсне връзката. Неактивните слотове за репликация причиняват задържане на WAL файлове, тъй като те ще трябва да бъдат изпратени на клиента, когато се свърже отново и слотовете станат активни. Всъщност първото нещо, което трябва да проверите дали броят на вашите WAL файлове не намалява, е да видите дали имате неактивни слотове за репликация.

Често неактивните слотове за репликация са резултат от премахнат клиент за архивиране, свален подчинен, повишения, откази и други подобни.

Действие:Непрекъснато проверявайте за неактивни слотове за репликация, предупреждавайте, ако има такива.

Как да:

-- returns the count of inactive replication slots
SELECT count(*)
  FROM pg_replication_slots
 WHERE NOT active;

4. Backends, чакащи заключване

SQL операторите могат изрично или имплицитно да причинят изчакване на други SQL оператори. Например, изпълнението на „SELECT .. FOR UPDATE“ изрично декларира заключване за тези избрани редове, а изпълнението на „UPDATE“ поставя имплицитни заключвания, изключващи редове. Други SQL оператори, когато срещне заключването, ще трябва да изчака, докато първият израз се откаже от заключването, преди да продължи изпълнението му.

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

Въпреки че известно количество заключване не може да бъде избегнато, нарастващата тенденция на бекендове, чакащи заключване, обикновено изисква преструктуриране на заявки или логика на приложението.

Действие:Наблюдавайте максималния брой бекендове, чакащи за заключване всеки ден/седмица, проучвайте нарастващите тенденции.

Как да:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE wait_event = 'Lock';

5. Бекенд неактивен в транзакция

Дългосрочните транзакции не са много приятни за правене в света на PostgreSQL. Те могат да причинят натрупване на WAL файлове, да предотвратят автоматично вакуумиране и ръчно вакуумиране и да изразходват ресурси. Нищо не може да се направи по отношение на истински транзакции, които отнемат много време за завършване, но има случаи като неправилно работещи приложения/скриптове и от време на време psql клиент, който стартира транзакции, но не ги затваря. Бекендовете, които обслужват такива клиенти, изглеждат като „неработещи в транзакция“.

Бекендовете, които не работят в транзакцията, трябва да бъдат открити и изключени, преди да започнат да влияят върху стабилността на системата.

Действие:Непрекъснато следете броя на неактивните сървъри в транзакцията, прегледайте дали има открити такива.

Как да:

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE state = 'idle in transaction';

6. Закъснение при репликация за активни връзки

Когато има активни клиенти за стрийминг репликация (като гореща готовност) или активни клиенти за логическа репликация, Postgres изпълнява системен бекенд, нареченWAL изпращач за всеки активен (свързан) клиент. Изпращачът на WAL е отговорен за изпращането на данните от WAL записа, от които се нуждае клиентът.

Клиентите за репликация обикновено се опитват да се справят колкото могат повече с първичния. Понякога обаче скоростта на генериране на WAL на първичната страна може да стане по-висока от скоростта, с която клиентът е в състояние да ги консумира. Това води до закъснение при репликация за всяка връзка за репликация.

PostgreSQL предоставя механизъм за заявка за забавяне на записа (брой байтове, изпратени, но незаписани на диска на клиента), забавяне на изтриване (брой записани, но непрочистени байтове на диска на клиента) и забавяне на повторното възпроизвеждане (брой байтове, изчистени, но не преиграни в диска на клиента файлове от база данни) за всеки активен подател на WAL.

Действие:Непрекъснато следете забавянето на репликацията за активни връзки, предупреждавайте, ако стойностите надвишават зададените прагове.

Как да:

-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
       flush_lsn - write_lsn AS flush_lag,
       replay_lsn - flush_lsn AS replay_lag
  FROM pg_stat_replication;

7. Закъснение при репликация за слотове за репликация

Клиентите за копиране не само могат да изостават, но също така могат да изчезнат напълно поради сривове, промени в топологията или човешка грешка. Може също така да е по проект, при което клиентите не винаги са онлайн.

Ако клиентът е подкрепен от слот за репликация, тогава всички WAL файлове, необходими на клиента да продължи от точката, в която е спрял, се запазват от PostgreSQL. Файловете WAL ще се съхраняват за неопределено време – няма начин да се зададе ограничение. Когато клиентът се свърже отново, всички запазени данни трябва да се предават поточно към клиента, което може да включва много дисков и мрежов трафик на основния. Поради тези причини трябва да наблюдавате изоставането и на ниво слот.

(Забележка:Процесът на изпращача на WAL се изпълнява само когато клиентът е свързан и излиза, когато клиентът прекъсне връзката. Методът на изпращача на WAL за измерване колко далеч е клиентът не работи, когато клиентът е изключен.)

Действие:Непрекъснато следете забавянията на репликацията за логически слотове за репликация, предупреждавайте, ако стойностите надвишават зададен праг.

Как да:

-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
  FROM pg_replication_slots;

8. Брой файлове на WAL

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

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

Действие:Непрекъснато следете броя на WAL файловете, предупреждавайте, ако стойността надвиши зададен праг.

Как да:

-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
  FROM pg_ls_waldir();

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';

-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'

9. Брой готови за архивиране WAL файлове

Когато WAL архивирането е активирано, PostgreSQL извиква потребителски скрипт всеки път, когато се генерира нов WAL файл. Предполага се, че скриптът „архивира“ единичния WAL файл, за който е бил извикан (обикновено го копира на друг сървър или S3 кофа). бъде архивиран, натрупва се.

Действие:Непрекъснато следете броя на файловете, готови за архивиране на WAL, предупреждавайте, ако стойността надвишава зададен праг.

Как да:

-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
  FROM pg_ls_archive_statusdir()
 WHERE name ~ '^[0-9A-F]{24}.ready$';

-- same, for v10+
SELECT count(*)
  FROM pg_ls_dir('pg_wal/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .ready

Събиране на тези показатели

Разделите по-горе предоставят SQL изрази за извличане на необходимите показатели от работещ Postgres сървър. Ако предпочитате да не пишете сами скриптовете, разгледайте инструмента с отворен код pgmetrics. Може да събира показателите по-горе и други и да ги отчита в текстови и JSON формати.

Можете директно да изпращате отчетите за pgmetrics до нашето търговско предложение, pgDash, което съхранява и обработва тези отчети, за да показва графики и да извършва сигнали.

Напред

Допълнителни части от тази серия ще обхващат метрики на ниво база данни, ниво на таблица, ниво на индекс и ниво на системата. Останете на линия!