VACUUM и ANALYZE са двете най-важни операции за поддръжка на база данни на PostgreSQL.
Вакуумът се използва за възстановяване на пространство, заето от „мъртви кортежи“ в таблица. Мъртъв кортеж се създава, когато записът бъде или изтрит, или актуализиран (изтриване, последвано от вмъкване). PostgreSQL не премахва физически стария ред от таблицата, но поставя „маркер“ върху него, така че заявките да не връщат този ред. Когато се изпълнява вакуумен процес, пространството, заето от тези мъртви кортежи, се маркира за повторно използване от други кортежи.
Операцията „анализ“ прави това, което казва името й – анализира съдържанието на таблиците на базата данни и събира статистически данни за разпределението на стойностите във всяка колона на всяка таблица. Системата за заявки на PostgreSQL използва тези статистически данни, за да намери най-добрия план за заявка. Тъй като редовете се вмъкват, изтриват и актуализират в база данни, статистиката на колоните също се променя. ANALYZE – стартира се ръчно от DBA или автоматично от PostgreSQL след автоматично вакуумиране – гарантира, че статистическите данни са актуални.
Въпреки че звучат сравнително просто, задкулисието, вакуумирането и анализирането са два сложни процеса. За щастие DBA не трябва да се тревожат много за своите вътрешни органи. Те обаче често са объркани относно ръчното изпълнение на тези процеси или задаване на оптималните стойности за параметрите на конфигурацията.
В тази статия ще споделим няколко най-добри практики за ВАКУУМ и АНАЛИЗ.
Съвет 1:Не стартирайте ръчно ВАКУУМУВАНЕ или АНАЛИЗ без причина
Прахосмукачването на PostgreSQL (автовакуум или ръчно вакуумиране) минимизира раздуването на таблицата и предотвратява обвиването на идентификатора на транзакции. Autovacuum не възстановява дисковото пространство, заето от мъртвите кортежи. Въпреки това се изпълнява VACUUM FULL командата ще направи това. VACUUM FULL обаче има своите последици за производителността. Целевата таблица е изключително заключена по време на операцията, предотвратявайки дори четене на таблицата. Процесът също така прави пълно копие на таблицата, което изисква допълнително дисково пространство, когато се изпълнява. Препоръчваме да не изпълнявате VACUUM FULL, освен ако няма много висок процент на раздуване и заявките страдат сериозно. Също така препоръчваме да използвате периоди на най-ниска активност на базата данни за него.
Също така е най-добрата практика да не изпълнявате твърде често ръчно почистване на цялата база данни; целевата база данни може вече да бъде оптимално вакуумирана чрез процеса на автоматично вакуумиране. В резултат на това ръчният вакуум може да не премахне мъртвите кортежи, но да причини ненужни I/O натоварвания или CPU пикове. Ако е необходимо, ръчните прахосмукачки трябва да се изпълняват само на база маса по маса, когато има нужда от това, като ниски съотношения на живи редове към мъртви редове или големи пропуски между автоматично вакуумиране. Също така, ръчните прахосмукачки трябва да се изпълняват, когато активността на потребителите е минимална.
Autovacuum също така поддържа актуални статистиките за разпределение на данни в таблицата (не ги възстановява). Когато се стартира ръчно, АНАЛИЗ командата всъщност възстановява тези статистики, вместо да ги актуализира. Отново, възстановяването на статистически данни, когато те вече са оптимално актуализирани чрез редовно автоматично вакуумиране, може да причини ненужен натиск върху системните ресурси.
Времето, когато трябва да стартирате ANALYZE ръчно, е веднага след груповото зареждане на данни в целевата таблица. Голям брой (дори няколкостотин) нови редове в съществуваща таблица значително ще изкривят разпределението на данните в колоните. Новите редове ще доведат до неактуалност на всички съществуващи статистически данни за колони. Когато оптимизаторът на заявки използва такава статистика, производителността на заявката може да бъде наистина бавна. В тези случаи изпълнението на командата ANALYZE веднага след зареждане на данни за пълно възстановяване на статистическите данни е по-добър вариант, отколкото да чакате автоматичното вакуумиране да започне.
Съвет 2:Фина настройка на прага за автоматично вакуумиране
Важно е да проверите или настроите автоматично вакуумиране и да анализирате конфигурационните параметри в postgresql.conf файл или в свойства на отделна таблица, за да постигнете баланс между автоматично вакуумиране и повишаване на производителността.
PostgreSQL използва два конфигурационни параметъра, за да реши кога да стартира автоматично вакуумиране:
- autovacuum_vacuum_threshold :това има стойност по подразбиране 50
- autovacuum_vacuum_scale_factor :това има стойност по подразбиране от 0,2
Заедно тези параметри казват на PostgreSQL да стартира автоматично вакуумиране, когато броят на мъртвите редове в таблицата надвиши броя на редовете в тази таблица, умножен по коефициента на мащаба плюс прага на вакуума. С други думи, PostgreSQL ще започне автоматично вакуумиране на маса, когато:
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
За малки до средни маси това може да е достатъчно. Например, таблица с 10 000 реда, броят на мъртвите редове трябва да бъде над 2050 ((10 000 x 0,2) + 50), преди да започне автоматично вакуумиране.
Не всяка таблица в база данни изпитва еднаква скорост на промяна на данните. Обикновено няколко големи таблици ще изпитват чести модификации на данни и в резултат на това ще имат по-голям брой мъртви редове. Стойностите по подразбиране може да не работят за такива таблици. Например, със стойностите по подразбиране, таблица с 1 милион реда ще трябва да има повече от 200 050 мъртви реда, преди да започне автоматично вакуумиране ((1000 000 x 0,2) + 50). Това може да означава по-дълги интервали между автоматично вакуумиране, все по-дълго време за автоматично вакуумиране и още по-лошо, автоматичното вакуумиране да не работи изобщо, ако активните транзакции на масата го заключват.
Следователно целта трябва да бъде тези прагове да бъдат зададени на оптимални стойности, така че автоматичното вакуумиране да може да се извършва на редовни интервали и да не отнема много време (и да повлияе на потребителските сесии), като същевременно поддържа относително нисък броя на мъртвите редове.
Един подход е да се използва един или друг параметър. Така че, ако зададем autovacuum_vacuum_scale_factor на 0 и вместо това зададем autovacuum_vacuum_threshold на, да речем, 5000, таблица ще бъде автоматично вакуумирана, когато броят на мъртвите редове е повече от 5000.
Съвет 3:Фина настройка на прага за автоматичен анализ
Подобно на автоматично вакуумиране, autoanalyze също използва два параметъра, които решават кога автоматично вакуумиране също ще задейства автоматичен анализ:
- autovacuum_analyze_threshold :това има стойност по подразбиране 50
- autovacuum_analyze_scale_factor :това има стойност по подразбиране 0.1
Подобно на autovacuum, параметърът autovacuum_analyze_threshold може да бъде зададен на стойност, която диктува броя на вмъкнатите, изтрити или актуализирани кортежи в таблица, преди да започне автоматичният анализ. Препоръчваме да зададете този параметър отделно за големи таблици и таблици с големи транзакции. Конфигурацията на таблицата ще замени стойностите на postgresql.conf.
Кодовият фрагмент по-долу показва SQL синтаксиса за промяна на настройката autovacuum_analyze_threshold за таблица.
ALTER TABLE <table_name> SET (autovacuum_analyze_threshold = <threshold rows>)
Съвет 4:Прецизно настройване на работещите в автовакуум
Друг параметър, който често се пренебрегва от администраторите на база данни, е autovacuum_max_workers , който има стойност по подразбиране 3. Autovacuum не е единичен процес, а няколко отделни вакуумни нишки, работещи паралелно. Причината за посочване на множество работници е да се гарантира, че вакуумирането на големи таблици не задържа вакуумирането на по-малки таблици и потребителски сесии. Параметърът autovacuum_max_workers казва на PostgreSQL да увеличи броя на работните нишки за автоматично вакуумиране, за да извърши почистването.
Често срещана практика на PostgreSQL DBA е да се увеличи броят на максималните работни нишки с надеждата, че това ще ускори автоматичното вакуумиране. Това не работи, тъй като всички нишки споделят едно и също autovacuum_vacuum_cost_limit , което има стойност по подразбиране 200. На всяка нишка за автоматично вакуумиране се присвоява ограничение на разходите, като се използва тази формула, показана по-долу:
individual thread’s cost_limit = autovacuum_vacuum_cost_limit / autovacuum_max_workers
Цената на работата, извършена от автовакуумна нишка, се изчислява с помощта на три параметъра:
- vacuum_cost_page_hit :това има стойност по подразбиране 1
- vacuum_cost_page_miss :това има стойност по подразбиране 10
- vacuum_cost_page_dirty :това има стойност по подразбиране 20
Какво означават тези параметри е следното:
- Когато вакуумна нишка намери страницата с данни, която трябва да почисти в споделения буфер, цената е 1.
- Ако страницата с данни не е в споделения буфер, а в кеша на ОС, цената ще бъде 10.
- Ако страницата трябва да бъде маркирана като мръсна, защото вакуумната нишка трябваше да изтрие мъртвите редове, цената ще бъде 20.
Увеличеният брой работни нишки ще намали границата на разходите за всяка нишка. Тъй като на всяка нишка е присвоена по-ниска граница на разходите, тя ще заспива по-често, тъй като прагът на разходите се достига лесно, което в крайна сметка води до бавно протичане на целия вакуумен процес. Препоръчваме да увеличите autovacuum_vacuum_cost_limit до по-висока стойност, като 2000, и след това да коригирате максималния брой работни нишки.
По-добър начин е да настроите тези параметри за отделни таблици само когато е необходимо. Например, ако автоматичното вакуумиране на голяма таблица за транзакции отнема твърде много време, таблицата може временно да бъде конфигурирана да използва собствено ограничение на разходите за вакуум и закъснения на разходите. Ограничението на разходите и забавянето ще отменят стойностите за цялата система, зададени в postgresql.conf.
Кодовият фрагмент по-долу показва как да конфигурирате отделни таблици.
ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_limit = <large_value>) ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_delay = <lower_cost_delay>)
Използването на първия параметър ще гарантира, че автовакуумната нишка, присвоена на масата, ще извърши повече работа, преди да заспи. Намаляване на autovacuum_vacuum_cost_delay също така ще означава, че нишката спи по-малко време.
Последни мисли
Както можете да видите, промяната на конфигурационните параметри за вакуум и анализ е лесна, но първо се нуждае от внимателно наблюдение. Всяка база данни е различна по отношение на своя размер, модел на трафик и скорост на транзакции. Препоръчваме DBA да започнат със събиране на достатъчно информация за своята база данни, преди да променят параметрите или да разгърнат режим на ръчно вакуумиране/анализ. Такава информация може да бъде:
- Брой редове във всяка таблица
- Брой мъртви кортежи във всяка таблица
- Времето на последното вакуумиране за всяка маса
- Времето на последния анализ за всяка таблица
- Процентът на вмъкване/актуализиране/изтриване на данни във всяка таблица
- Времето, необходимо за автоматично вакуумиране за всяка маса
- Предупреждения относно таблиците, които не се почистват с прахосмукачка
- Текуща производителност на повечето критични заявки и таблиците, до които имат достъп
- Изпълнение на същите заявки след ръчно вакуумиране/анализ
Оттук администраторите на база данни могат да изберат няколко „пилотни“ таблици, за да започнат да оптимизират. Те могат да започнат да променят свойствата за вакуум/анализ за таблиците и да проверят производителността. PostgreSQL е интелигентна машина за бази данни – администраторите на база данни често намират, че вероятно е най-добре да оставят PostgreSQL да извършва вакуумирането и анализирането, вместо да ги прави ръчно.
