Какви показатели за внедряването на PostgreSQL трябва да наблюдавате? Тази серия от публикации в блога има за цел да предостави минимален, начален набор от основни действия за наблюдение, които трябва да приложите, за да гарантирате здравето и стабилността на вашите Postgres сървъри.
Това е втората част от поредица от блогове и обхваща параметри на ниво база данни. Първата обхваща параметри на ниво клъстер.
Част 2:Ниво на база данни
В тази част разглеждаме показателите и информацията, които трябва да се наблюдават за всяка важна база данни, която използвате.
Повечето от изброените по-долу SQL заявки трябва да се изпълняват, докато са свързани с въпросната база данни.
1. Свързани клиенти
Свързаните клиенти заемат ОС и системни ресурси. Postgres има архитектура процес на клиент и твърде много клиенти могат да забавят времето за отговор на заявката за всички. Помислете за използването на PgBouncer orpgpool, за да намалите броя на връзките, които Postgres сървърът ще трябва да обслужва.
Следете промените в изходното ниво след актуализации на приложенията и скокове във връзките поради увеличения трафик.
Действие:Наблюдавайте максималния брой свързани клиенти през всеки ден/седмица, проучвайте промените в тенденцията.
Как да:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Размер
Трябва да се следи действителният размер на диска, използван от базата данни. В повечето случаи размерът на базата данни продължава да расте, така че темпът на растеж е по-интересен. Отново, внимавайте с повишена скорост на растеж след нови издания на приложения.
Действие:Следете нарастването на размера на базата данни през всяка седмица/месец, проучвайте тенденциите, предоставяйте повторно.
Как да:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Раздуване на масата на всички маси
Поради MVCC архитектурата на Postgres, по-старите версии на редовете се намират във файловете с физически данни за всяка таблица и се наричат раздуване . Операцията за изчистване на остарели версии на ред се нарича вакуум . Postgres изпълнява фонов процес, наречен autovacuum , който събира таблици кандидати (въз основа на конфигурируеми параметри) и ги изчиства вместо вас.
Bloat забавя операциите с таблицата и губи дисково пространство и може да избяга дори при автоматично вакуумиране. Изисква се наблюдение на раздуването, като абсолютен брой байтове, както и процент (от мъртвите данни към общите данни). Това може да се направи на ниво база данни като общо за всички таблици, с възможност за разбивка до „най-раздутите таблици“.
Действие:Непрекъснато следете общото раздуване като байтове и проценти, предупреждавайте, ако стойностите надхвърлят зададения праг.
Как да:
Използвайте check_postgres orpgmetrics, за да получите приблизителни оценки. Вижте thewiki за повече информация.
4. Раздуване на индексите във всички индекси
Раздутите индекси могат да забавят вмъкването и да намалят производителността на търсене. Наблюдавайте раздуването на индексите като абсолютна стойност (брой байтове) и като процент. Индексите ще трябва да бъдат възстановени, когато станат твърде раздути.
Действие:Непрекъснато следете общото раздуване като байтове и проценти, предупреждавайте, ако стойностите надхвърлят зададения праг.
Как да:
Използвайте check_postgres orpgmetrics, за да получите приблизителни оценки. Вижте thewiki за повече информация.
5. Дълго текущи транзакции
Транзакциите, отворени твърде дълго, не са добра новина за PostgreSQL. Продължителните транзакции могат да доведат до задържане на WAL файлове, да се задържат за брави и да предотвратят вакуумиране. Приложенията трябва да бъдат проектирани така, че да поддържат продължителността на транзакциите възможно най-ниска.
Бекенд, изпълняващ продължителна транзакция, може да бъде убит с pg_cancel_backend() и pg_terminate_backend() функции.
Действие:Непрекъснато следете броя на транзакциите, които се изпълняват за повече от определено време, предупреждавайте, ако стойностите надхвърлят зададения праг.
Как да:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Блокировки
В PostgreSQL, бекендовете поставят ключалки на редове и таблици имплицитно, докато става въпрос за изпълнение на заявки, които променят редове. Заявките могат също да поставят изрични заключвания (като SELECT .. FOR UPDATE ). Точно както при многонишковото програмиране, две транзакции, поставящи заключвания, имплицитно или изрично, в противоположния ред, могат да доведат до безизходица.
PostgreSQL ще открие задънки и ще отмени една от включените транзакции (Всички заключвания, държани от транзакция, се освобождават, когато тя бъде ангажирана или върната обратно). Подробностите ще бъдат записани в дестинацията за регистриране на PostgreSQL.
Приложенията трябва да бъдат проектирани така, че да се избягва възможността за блокиране. Те могат също да изберат да опитат отново транзакция в случай на застой.
Действие:Наблюдавайте броя на блокирането през всеки ден/седмица, препроектирайте приложението, за да намалите броя, проучвайте промените.
Как да:
Появата на застой, заедно с допълнителна информация, се регистрират в регистрационния файл на PostgreSQL. Използвайте pgmetrics, pgbadger или други инструменти за обработка на журнали, специфични за PostgreSQL, за да извлечете тази информация.
7. Най-старият вакуум
Редовното почистване на маси с прахосмукачка, било с автоматично вакуумиране, или с планирани задачи, или ръчно е задължително за поддържане на операциите на масата бързо. Вакуумите могат да се провалят по различни причини, включително продължителни транзакции, неактивни репликационни слотове и т.н.
Тъй като редовното почистване на таблици с прахосмукачка е доста важно в света на Postgres, най-добре е редовно да проверявате дали всички маси са били почистени с прахосмукачка поне веднъж в зададен интервал.
И въпреки че обикновено не се виждат и не се виждат, системните каталожни таблици също трябва да бъдат почистени с прахосмукачка.
Действие:Непрекъснато проверявайте дали някоя маса не е била почистена с прахосмукачка през последния зададен брой часове/дни, предупреждавайте, ако има такива.
Как да:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Най-старият анализ
За да изпълните вашите SELECT заявки, планировщика на заявки изготвяплан за изпълнение който описва кои индекси и таблици трябва да се четат и как. За да излезе с ефективен план за изпълнение, плановникът трябва да има статистика за разпределението на стойностите, размерите на кортежи и т.н. Такава статистическа информация за данните в таблица се събира и поддържа чрез анализ операции. Таблиците с актуални статистически данни водят до по-бързи заявки и по-малко I/O.
Процесът на автоматично вакуумиране, споменат по-горе, обикновено също изпълнява АНАЛИЗ на масата той вакуумира, за да поддържа тази информация актуализирана. Това обаче само по себе си може да не осигури достатъчно покритие на анализа за вашите таблици. Ще искате да допълните, като стартирате ANALYZE като планирани задачи или след значителни мутации на таблица.
В интерес на ефективността на заявката е най-добре непрекъснато да проверявате дали всички таблици са били анализирани поне веднъж в зададен интервал.
Действие:Непрекъснато проверявайте дали някоя таблица не е била анализирана през последния зададен брой часове/дни, предупреждавайте, ако има такива.
Как да:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Събиране на тези показатели
Разделите по-горе предоставят SQL изрази за извличане на необходимите показатели от работещ Postgres сървър. Ако предпочитате да не пишете сами скриптовете, разгледайте инструмента с отворен код pgmetrics. Може да събира показателите по-горе и други и да ги отчита в текстови и JSON формати.
Можете директно да изпращате отчетите за pgmetrics до нашето търговско предложение, pgDash, което съхранява и обработва тези отчети, за да показва графики и да извършва сигнали.
Напред
Следващата част от тази серия ще обхване метрики на ниво таблица, ниво на индекс и ниво на системата. Останете на линия!
