Малко грижи и поддържане на вашето внедряване на PostgreSQL са дълъг път за осигуряване на производителност, избягване на неприятни открития и установяване на уверена предсказуемост. Ето 7 неща, които трябва да следите.
Раздуване на маса
PostgreSQL реализира транзакции с помощта на техника, наречена MVCC.MVCC е твърде дълъг и включва тема за обсъждане в детайли, но иматри неща, които трябвате знам за това:
- Изтриването на ред само го маркира като „невидим“ за бъдещи транзакции.
- Актуализирането на ред създава нова версия на реда. Старата версия е маркирана като невидима за бъдещи транзакции, а новата версия е маркирана като видима.
- Периодично някой трябва да прегледа всички изпълнявани в момента транзакции и да каже:Добре, най-старата транзакция тук е #42, така че всяка версия на ред, която е невидима за #42, може да бъде физически изтрита, без да се нарушава последователността на данните.
Ето как работи MVCC (по същество) и внушението е, че актуализациите ще увеличете отпечатъка на вашата физическа база данни за съхранение и изтриванията няма намалете. MVCC звучи като мързелив начин за правене на неща, но е популярен, защото осигурява както последователност, така и производителност.
Нежеланите, остарели версии на редове в таблица се наричат раздуване (или deadrows ). Процесът, който може да премахне подуването, се нарича вакуум . PostgreSQL има автоматично задействан вакуумен процес с регулируеми прагове, наречени autovacuum, и разбира се командата VACUUM.
Като цяло, раздуването може също да забави заявките поради неточни карти на видимостта и пропилян дисков вход/изход.
Поради това трябва редовно:
- следете количеството раздуване в база данни
- пускайте редовно прахосмукачката
- следете дали вакуумът се изпълнява редовно за всички маси
Има няколко SQL заявки за предоставяне на оценки за раздуване на таблица. Инструментите с отворен код предоставят оценки за раздуване, както и времето за последно изпълнение на ръчно и автоматично вакуумиране.
Надуване на индекса
Индексите също могат да се надуят. Въпреки че вътрешната структура на индексите е непрозрачна за потребителя на SQL и варира в зависимост от типа на индекса (BTree, hash, GIN, GIST и т.н.), остава общата идея, че когато се изтриват редове, посочени от индекса, пространството се заема от свързаната информация вътре в индекса се изтрива само логически и не се пуска обратно във файловата система. Логически изтритото пространство може да се използва повторно от индекса по-късно.
Има два начина да накарате Postgres да свие физическия размер на индекс:
- ПЪЛНАТА версия на командата VACUUM
- REINDEX
Надуването на индекса трябва да се следи, така че поне да сте наясно с количеството оставащо неизползвано пространство. В таблици с голяма отлив на редове не е необичайно да настроите редовни задачи за възстановяване на индекс.
Раздуването на индексите може да бъде получено и чрез същите заявки както преди, а също и чрез pgmetrics.
Дълго текущи транзакции
Транзакциите трябва да бъдат възможно най-кратки, особено в MVCC система.
Представете си, че транзакция е започнала вчера и е имало вакуумно изпълнение точно след това. Докато тази транзакция е отворена, по-нататъшните вакууми са безполезни, тъй като по дефиниция нашата транзакция ще трябва да вижда всички редове на всички таблици, както са били, когато транзакцията ни е започнала вчера. Дори ако нашата транзакция е само за четене, това все още е така.
В резултат на това продължителните транзакции създават надуване. Те също така поддържат системните ресурси, държат неотменени ключалки и увеличават шансовете за блокиране.
Най-добрият начин да следите дългосрочните транзакции е да настроите предупреждение за броя на транзакциите, които се изпълняват повече от определена продължителност. Можете да получите това от изгледа на статистикатаpg_stat_activity , така:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Закъснение при репликация
Когато стрийминг репликацията се използва за репликиране на всички промени от първичен PostgreSQL сървър към горещ режим на готовност (известен още като реплика за четене), обикновено има малко забавяне между времето, когато се случват актуализации на редовете на основния и когато промените са видими за приложения, свързани към режим на готовност .
Има обаче случаи, когато това изоставане може да се увеличи:
- системата в режим на готовност не е в състояние да получи и приложи промените от първичната достатъчно бързо, за да бъде в крак с нея, обикновено поради голямо натоварване или недостатъчно обезпечаване.
- влошена мрежа или диск
- конфликти на заявки
Режим на готовност с голямо или дори по-лошо, увеличаващо се забавяне на репликацията може да доведе до запитвания в режим на готовност, връщащи остарели данни, и режим на готовност, който е негоден за отказ.
Ако имате настройка за поточно репликация, наблюдението на забавянето на репликацията между всяка двойка първичен режим на готовност е много важно и ще искате да зададете upalerts, за да проверите дали забавянето на репликацията надвишава една минута или какъвто праг има смисъл за вашата настройка.
Тази публикация има много повече за това как да измерваме и наблюдаваме забавянето на репликацията както от първичния, така и от резервния край.
Неактивни слотове за репликация
Използването на слотове за репликация, въведено в PostgreSQL 9.4, прави стрийминг репликацията по-стабилна и ефективна. По същество режимът на готовност отчита напредъка на репликацията на основния, който съхранява тази информация в „слота за репликация“.
Поради това първичният вече знае по всяко време колко е изостанал от режима на готовност. Това позволява на основния да запази достатъчно изоставане от WAL файлове (които са необходими за възобновяване на репликацията), когато режимът на готовност излезе офлайн. По този начин, когато режимът на готовност се върне, дори след дълго време, първичният все още може да гарантира, че репликацията може да бъде възобновена.
Преди слотове за репликация, първичният може да почисти стари WAL файлове, тъй като нямаше как да знае дали в режим на готовност се нуждаят от тях или не. Ако WAL файл, необходим за режим на готовност, бъде изтрит, няма начин да се възобнови репликацията; трябва да се настрои отново от нулата.
Въпреки това, поведението на първичния за запазване на WAL файлове за неопределено време води до друг проблем. Ако режимът на готовност е бил оттеглен и свързаният слот за репликация не е бил изтрит, WAL файловете ще бъдат запазени завинаги. WAL файловете, запазени по тази причина, не подлежат на ограниченията, зададени от max_wal_size и други опции за конфигуриране.
Тази ситуация ще продължи, докато WAL файловете изядат цялото дисково пространство, без дори да има предупреждение в регистрационните файлове на PostgreSQL.
Излишно е да казвам, че неактивните слотове за репликация трябва да бъдат третирани, когато бъдат открити. Намерете вашите неактивни слотове за репликация, като използвате:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Състояние на анализа
ANALYZE се изпълнява на таблици за събиране и актуализиране на статистическа информация за съдържанието на таблицата. Тази информация се използва от планировчика на заявки, за да подготви плана за изпълнение за всяка SQL заявка. Актуалните статистически данни за съдържанието на таблицата водят до по-добър план за изпълнение, което от своя страна води до по-бърза заявка.
Демонът за автоматично вакуумиране обикновено стартира ANALYZE след VACUUM. Това обаче може да не е достатъчно често за АНАЛИЗ. Ако разпределението от данните, които могат да се променят често, трябва да изпълнявате ANALYZE по-често.
Обикновено ANALYZE се държи доста добре – има нужда само от заключвания за четене, не изразходва твърде много от ресурсите и завършва за разумно време. Безопасно е да го пускате по-често, отколкото не.
Да следите за таблици, които не са били АНАЛИЗИРАНИ от известно време, е добра идея. Разберете последния път, когато вашите таблици са били (автоматично) анализирани със заявката:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Използване на ресурси
Мониторингът на натоварването на процесора, паметта и използването на диска е дълъг път, за да се гарантира, че ще имате достатъчно капацитет, за да посрещнете нарастващите нужди на приложенията, използващи вашата база данни.
PostgreSQL създава един процес за обработка на една връзка. Въпреки че това може да не е най-мащабируемата архитектура в днешно време, тя допринася много за стабилността. Освен това прави средното натоварване на ОС по-смислено. Както обикновено PostgreSQLboxes изпълняват само PostgreSQL, средно натоварване, да речем 3, обикновено означава, че има 3 връзки, които чакат процесорните ядра да станат достъпни, за които могат да бъдат насрочени. Мониторингът на средното ви максимално натоварване през един типичен ден или седмица може да даде оценка за това колко прекомерно или недостатъчно е обезпечена кутията ви отпред на процесора.
Разбира се, паметта и свободното дисково пространство са стандартни неща за наблюдение. Повече връзки и по-продължителни транзакции поставят по-високи изисквания към паметта. И докато наблюдавате свободното дисково пространство, не забравяйте да го проследявате по пространство на таблица.
