Управлението на бази данни не е малка задача и лесно може да бъде разочароващо, без да знаете какво се случва под завивките. Независимо дали се опитвате да разберете дали новите индекси са полезни, броят на транзакциите в база данни в определен момент или кой е свързан към базата данни в даден момент, данните, които позволяват на администраторите наистина да знаят как се представят техните бази данни, са важни. За щастие с PostgreSQL тези данни за всичко това са налични в системния каталог на PostgreSQL.
Системният каталог на PostgreSQL е схема с таблици и изгледи, които съдържат метаданни за всички други обекти в базата данни и др. С него можем да открием кога се случват различни операции, как се осъществява достъп до таблици или индекси и дори дали системата на базата данни чете информация от паметта или трябва да извлича данни от диск.
Тук ще разгледаме преглед на системния каталог и ще подчертаем как да го прочетете и как да извлечете полезна информация от него. Някои от метаданните са ясни, а други изискват малко усвояване, за да генерират истинска полезна информация. Така или иначе, PostgreSQL ни дава страхотна платформа за изграждане на каквато и да е необходима информация за самата база данни.
Каталогът на PostgreSQL
PostgreSQL съхранява информацията за метаданните за базата данни и клъстера в схемата „pg_catalog“. Тази информация се използва частично от самия PostgreSQL за проследяване на нещата, но също така е представена, така че външните хора/процеси да могат да разберат и вътрешността на базите данни.
Каталогът на PostgreSQL има доста солидно правило:Вижте, не докосвайте. Докато PostgreSQL съхранява цялата тази информация в таблици, както би направило всяко друго приложение, данните в таблиците се управляват изцяло от самия PostgreSQL и не трябва да се променят, освен ако не е абсолютна спешна ситуация и дори тогава е вероятно повторно изграждане след това.
Ще разгледаме няколко полезни каталожни таблици, как да четем данните и умни неща, които можем да правим със самите данни. В каталога има доста таблици, които няма да разглеждаме, но цялата информация за тези различни таблици може да бъде намерена в официалната документация на PostgreSQL.
Метаданни за цялата система
Голяма част от таблиците, които можем да потърсим в каталога, са таблици за цялата система, където няма значение с коя база данни сме свързани, данните представляват целия клъстер, без единична база данни.
Информация за базата данни
Общата информация за базата данни се съхранява в pg_database, а статистическите данни се съхраняват в pg_stat_database.
pg_database:
postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid | 16396
datname | severalnines
datdba | 10
encoding | 6
datcollate | en_US.UTF-8
datctype | en_US.UTF-8
datistemplate | f
datallowconn | t
datconnlimit | -1
datlastsysoid | 13804
datfrozenxid | 548
datminmxid | 1
dattablespace | 1663
datacl |Таблицата pg_database съдържа ред за всяка база данни в клъстера, включително трите, които излизат от кутията (postgres, template0 и template1). Този ред съдържа информация за кодиране, ограничение на връзката и други основни метаданни.
Колони, представляващи интерес:
oid - Идентификаторът на обекта, който не се появява в изхода на заявката, освен ако не е посочен директно. Този номер ще съответства на директория в директорията с данни на клъстерите
datname - Името на базата данни.
datdba - Собственикът на базата данни, oid препратки pg_authid .oid.
encoding - Кодирането на знаци за тази база данни, pg_encoding_to_char() ще се преобразува в четливо име.
datconnlimit - Максималният брой едновременни връзки, разрешени в базата данни.
dattablespace - таблично пространство по подразбиране за тази база данни, препратки към pg_tablespace.oid.
pg_stat_database:
postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid | 13805
datname | postgres
numbackends | 2
xact_commit | 477460
xact_rollback | 13
blks_read | 417
blks_hit | 16488702
tup_returned | 252376522
tup_fetched | 2637123
tup_inserted | 114
tup_updated | 3
tup_deleted | 1
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
blk_read_time | 0
blk_write_time | 0
stats_reset | 2018-02-04 19:52:39.129052+00Тази статистическа таблица е мястото, където получаваме интересни и полезни данни. Всеки ред в тази таблица съдържа данни в реално време за всяка база данни и може да се експортира периодично, за да се проследява във времето, ако желаете да наблюдавате промените.
Транзакции
Информацията за транзакциите може да бъде намерена в колоните xact_commit и xact_rollback, които съдържат съответно броя транзакции, които базата данни е извършила и върнала назад. Това ще помогне да се покаже колко активна е дадена база данни, както и да се открият възможни сривове с програми, които може да допускат грешки/връщане назад с тревожна скорост.
Достъп до диск и памет
Информацията за това дали данните се извличат от диск или памет се съхранява в колоните blks_read и blks_hit. Blks_read показва броя на блоковете, прочетени от тази база данни от диска, докато blks_hit показва броя на блоковете, които са открити в буферния кеш на PostgreSQL (представен от параметъра shared_buffers). Тъй като RAM паметта е много по-бърза от диска, в идеалния случай бихме виждали blks_hit постоянно по-висок от blks_read и ако не, можем да преоценим наличната си памет.
Корчета
Следващите няколко колони се занимават с кортежи. Tup_returned е броят на редовете, върнати в базата данни, който е броят на редовете, прочетени от последователни сканирания, ако е от таблица, или броят на записите в индекса, върнати от индекс”. Tup_fetched е броят на редовете, извлечени в базата данни, което означава, че са били резултат от сканиране на растерни карти, което е броят на редовете на таблицата, извлечени чрез сканиране на растерни карти, ако е от таблица, или редовете на таблицата, извлечени чрез просто сканиране на индекс, ако се използва индекс.
Имаме също и tup_inserted, tup_updated и tup_deleted, които представляват съответно броя на вмъкнатите, актуализирани и изтрити кортежи в тази база данни. Това ще ви помогне да разберете как данните влизат, променят се и напускат базата данни. Тъй като актуализираните и изтритите кортежи водят до мъртви редове, високите стойности в тези колони биха предложили операциите за автоматично вакуумиране да бъдат настроени така, че да отговарят на нуждите на дейността на базата данни.
Конфликти
Ако въпросната база данни е сървър в режим на готовност, конфликтите в колоните са полезни като начин да се проследи колко заявки са били отменени поради конфликти с готовността да е в „режим на възстановяване“. Ако не е клъстер в режим на готовност, тази колона може да бъде игнорирана.
Временни файлове/данни
Понякога заявките ще трябва да се записват във временни файлове. Това може да се случи, когато количеството work_mem, разпределено за връзката, е изразходвано и трябва да продължи операцията по сортиране на диска, а не в паметта. Колоната temp_files проследява броя на тези файлове, които са били създадени, а temp_bytes проследява общия размер на всички използвани временни файлове. Тези данни могат да помогнат за информиране за настройката на work_mem или дори за намиране на заявки, които биха могли да изискват повторно записване, ако размерът на временния файл е твърде голям.
Застой
Колоната за блокиране проследява колко пъти възниква блокиране. Тъй като блокирането може да причини грешки за заявки, които иначе не биха допуснали грешка, добре е да проследите това и да се уверите, че приложенията не стъпват едно на друго.
Време за четене и запис
Колоните blk_read_time и blk_write_time проследяват общия брой милисекунди, които бекендовете в базата данни изразходват за четене и запис на данни, което може да бъде полезно, ако се опитвате да сравните/подобрите скоростта на четене/запис на диск
Нулиране на статистиката
Тази колона, stats_reset, просто показва времеви печат (с часова зона) на последния път, когато статистиката, спомената в този ред, е била нулирана. Нулева стойност означава, че те не са били нулирани от самото начало или дори е възможно срив на базата данни, което може да е изтрило тези статистически данни.
Контролни точки и фоновият запис
pg_stat_bgwriter
postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 47829
checkpoints_req | 2
checkpoint_write_time | 7323
checkpoint_sync_time | 38
buffers_checkpoint | 76
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 5
buffers_backend_fsync | 0
buffers_alloc | 440
stats_reset | 2018-02-04 19:52:34.712832+00Клъстерът PostgtreSQL управлява записването на данни на диск по няколко различни начина. По отношение на „мръсните буфери“ (данни в паметта, които са променени след четене от диск, но все още не са записани на диска), това се извършва или от контролна точка, или от фоновия запис. Тъй като мръсният буфер трябва да бъде записан на диска, преди да може да бъде освободен или преразпределен, гарантирането, че тези процеси са фино настроени, е от решаващо значение и тази таблица помага да се хвърли светлина върху това как работи всичко.
Контрольни точки
Контролна точка се случва или по график (представена от параметъра checkpoint_timeout), или когато е използвано максималното количество WAL файлове от последната контролна точка и трябва да наложи контролна точка. Така или иначе контролната точка записва мръсни буфери на диска и има четири колони, които го проследяват.
Колоните checkpoints_timed и checkpoints_req показват броя на планираните контролни точки, които се появяват (време) и броя на заявените контролни точки (наричани също принудителни). Висока стойност на изкачване на checkpoint_req може да предполага недостатъчна стойност на max_wal_size.
Колоните checkpoint_write_time и checkpoint_sync_time записват общото време (в милисекунди), което процесът на контролната точка е прекарал в писане и синхронизиране с диска.
И накрая, buffers_checkpoint е общият брой буфери, записани на диск от контролни точки.
Фонов запис
Фоновият запис е отделен процес, който записва мръсни буфери на диск, което в идеалния случай намалява количеството работа, която контролният указател трябва да свърши.
Колоната buffers_clean представлява броя на буферите, записани на диска от фоновия процес. В сравнение с buffers_checkpoint, той показва каква част от натоварването се обработва от всеки процес (с допълнителното знание, че фоновият записвач има възможността да записва буфери многократно, ако те се променят често, в сравнение с по-рядко с контролна точка с времеви интервал).
Maxwritten_clean представлява броя пъти, когато фоновият записвач е достигнал максималния брой страници за изчистване при всяко изпълнение (контролирано с параметъра bgwriter_lru_maxpages).
Буфери като цяло
Останалите колони ни показват общата информация за буфера, като buffers_backend е броят на буферите, които бекендът трябва да запише сам, вместо фонов записващ или контролен указател, buffers_backend_fsync е броят на колко пъти бекенд трябва да изпълни своето собствено fsync извикване и buffers_alloc показва броя на буферите, които са били разпределени като цяло.
Активност и заключвания в базата данни
Има два изгледа, които показват текущата потребителска активност, pg_stat_activity и pg_locks. Когато бъдат запитани, те показват информация за текущите връзки към базите данни и какъв вид заключвания имат за какви отношения.
pg_stat_activity
postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid | 13805
datname | severalnines
pid | 29730
usesysid | 10
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2018-07-21 02:29:48.976588+00
xact_start | 2018-07-21 02:30:03.73683+00
query_start | 2018-07-21 02:30:03.73683+00
state_change | 2018-07-21 02:30:03.736835+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 559
query | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type | client backendОбща информация
Изгледът pg_stat_activity показва ред за всяка връзка с базата данни и някаква основна информация за нея. Колоната datname представлява базата данни, към която връзката всъщност е свързана, pid е идентификаторът на процеса на връзката на самия хост на базата данни, а usesysid и usename представляват свързания потребител на базата данни.
За източника на клиента, client_addr е IP адресът на хоста, от който е дошла връзката, null означава, че това е връзка с локален unix сокет.
Чети за време
Има четири колони с времеви отпечатъци, които показват кога са започнали определени неща:backend_start е кога връзката е била действително установена, xact_start е кога е започнала текущата транзакция (нула, ако клиентът няма отворена транзакция), query_start е кога е започнала текущата или най-новата заявка, и state_change е времето, когато последното се е променило състоянието на връзката.
Състояние на връзката
Последните битове от pg_stat_activity покриват действителното състояние на връзката. Ако заявката чака друг, за да освободи заключванията, wait_event_type съдържа някаква информация за това какъв вид чакащо събитие е, а колоната wait_event ще покаже името на събитието чакане. Това е дълъг списък, но повече информация можете да намерите в документацията на PostgreSQL.
И накрая, колоната „състояние“ показва в какво състояние се намира текущата връзка, като например активна, неактивна, неактивна в транзакция, а колоната на заявката ще показва действителната заявка, която се изпълнява, или е извършена последно.
pg_lock
SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 3/475862
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 3/475862
pid | 29730
mode | ExclusiveLock
granted | t
fastpath | tТаблицата pg_locks работи ръка за ръка с pg_stat_activity, ако разглеждате активността на заявките. Всеки път, когато се направи заключване на връзка, тази информация се съхранява в pg_locks. Използвайки pid от pg_stat_activity, можем да потърсим pg_locks, за да видим какви отношения може да има заключвания на връзката, какви видове заключвания са и дали заключванията са предоставени или не.
Най-важните колони са 'pid', който съответства на pid от pg_stat_activity, 'relation', който съвпада с OID от pg_class, 'mode', показващ името на поддържания режим на заключване, и 'granted', който посочва дали заключването е или не въпросът е разрешен.
Информация за репликация
Тъй като PostgreSQL има вградени функции за репликация, има няколко изгледа, които хвърлят светлина върху производителността и състоянието на самата репликация.
Преглед на pg_stat_replication: съдържа ред за всеки процес на изпращач на WAL, съдържащ информация за неговото състояние, местоположението на WAL файловете, върху които работи, и информацията за връзката на хоста в режим на готовност, който получава WAL данните за репликация.
Преглед на pg_stat_wal_receiver: Ако клъстерът е в режим на готовност, това ще съдържа един ред, показващ статистически данни за процеса на приемника от хоста.
Преглед на pg_stat_subscription: Ако изпращате WAL данни към възел в режим на готовност, всеки ред тук ще представлява този абонамент и ще съдържа информация за състоянието на абонаментите.
Преглед на pg_replication_slots: Съдържа списък на всички слотове за репликация, които съществуват в клъстера, и тяхното текущо състояние.
Метаданни, специфични за базата данни
Вътре във всяка база данни има колекция от каталожни таблици, които имат информация, специфична за базата данни, която се запитва. Ако търсим конкретни данни от тези таблици, трябва да се уверим, че сме свързани с правилната база данни, докато изпращаме заявките.
Тук може да влезе сърцето на анализа на данни, където можем да видим как се осъществява достъп до нашите потребителски данни. От таблици, до индекси, до последователности, заявките, които идват в базата данни и извличат или променят данни, техните действия и въздействие ще се съхраняват в тези таблици и можем да разглеждаме тази информация, за да вземаме информирани решения относно управлението на базата данни надолу. път.
Метаданни на таблицата
Метаданните за нашите потребителски таблици се съхраняват в следните две таблици и всяка от тях има ред за всяка потребителска таблица, създадена в системата. Таблицата pg_stat_user_tables съдържа статистически данни за достъпа на потребителите до таблицата, докато pg_statio_user_tables съдържа I/O статистически данни за всяка таблица.
ЗАБЕЛЕЖКА:Данните тук не винаги са 100% перфектни и се разчита на чести анализи на таблиците, за да бъдат верни. Autoanalyze покрива това, но добра настройка на процеса на автоанализ, така че да може да поддържа добра статистика за всяка таблица. Ако изглежда, че статистическите данни са изключени, стартирането на ANALYZE ръчно върху таблицата ще ги опресни.
Таблица pg_stat_user_tables:
severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid | 2766788
schemaname | public
relname | history
seq_scan | 13817
seq_tup_read | 466841
idx_scan | 12251
idx_tup_fetch | 127652
n_tup_ins | 11
n_tup_upd | 13
n_tup_del | 3
n_tup_hot_upd | 13
n_live_tup | 3
n_dead_tup | 21
n_mod_since_analyze | 19
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0За статистиката на нашата потребителска таблица имаме доста данни.
Методи за достъп до таблица
Когато клиентите имат достъп до данни от таблицата, те правят това директно или чрез индекси. Колоната „seq_scan“ отчита броя на последователните сканирания на получената таблица, а „seq_tup_read“ брои броя на кортежи, прочетени през този процес. Колоната „idx_scan“ отчита колко пъти даден индекс в таблицата е бил използван за извличане на данни.
Активност на кортежа на таблица
Вече имаме шепа колони, които отчитат различни дейности в таблицата.
„n_tup_ins“ проследява броя на вмъкнатите кортежи
„n_tup_upd“ проследява броя на актуализираните кортежи
„n_tup_del“ проследява броя на изтритите кортежи
Състояние на кортежа на таблица
Поради актуализации и изтривания може да има мъртви кортежи, които вече не са активни данни и вакуумният процес в крайна сметка ще ги освободи. Колоните „n_tup_ins“ и „n_tup_ins“ проследяват броя на кортежи, които са живи и мъртви, съответно. Когато мъртвите кортежи достигнат определена точка, ще се стартира автоматично вакуумиране в зависимост от настройките за автоматично вакуумиране.
Вакуумна активност на масата
Поддръжката на таблицата се извършва или чрез VACUUM или AUTOVACUUM, а статистическите данни се събират чрез ANALYZE или AUTOANALYZE. Следващите четири колони съдържат датите за последното изпълнение на всяка от тези операции:„last_vacuum“, „last_autovacuum“, „last_analyze“, „last_autoanalyze“.
Имаме и четири по-удобни колони, които просто отчитат колко пъти се извършват предишните действия. Използвайки ги, можем да видим кои таблици получават най-голяма активност:„vacuum_count“, „autovacuum_count“, „analyze_count“ и „autoanalyze_count“.
Таблица pg_statio_user_tables:
severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid | 2766788
schemaname | public
relname | history
heap_blks_read | 4
heap_blks_hit | 63081
idx_blks_read | 5
idx_blks_hit | 44147
toast_blks_read | 0
toast_blks_hit | 0
tidx_blks_read | 0
tidx_blks_hit | 0I/O изходът е полезен за разбиране как се осъществява достъп до данните под кориците. Колоната „heap_blks_read“ представлява броя дискови блокове, прочетени за тази таблица, а „heap_blks_hit“ представлява буферните блокове, прочетени от паметта на тази таблица. Това е полезно, за да разберете дали заявките за достъп до таблицата постоянно трябва да отиват на диск или да извличат данните от паметта.
Индексната статистика в таблицата показва същата информация с колоните „idx_blks_read“ и „idx_blks_hit“.
И накрая, ако таблицата има таблици TOAST, колоните „toast_blks_hit“ и „toast_blks_read“ проследяват тост таблици, докато „tdix_blks_read“ и „tdix_blks_read“ проследява индексите на тези тост таблици.
Метаданни на индекса
pg_stat_user_indexes
severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_scan | 43910
idx_tup_read | 98147
idx_tup_fetch | 98147Подобно на колегите на таблицата, тази таблица съдържа информация конкретно за индексите. Един ред на индекс, тази таблица показва колко пъти индексът е бил сканиран с колоната „idx_scan“, колко кортежи са били прочетени с „idx_tup_read“ и колко живи реда всъщност са били извлечени с „idx_tup_fetch“.
pg_statio_user_indexes
severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_blks_read | 2
idx_blks_hit | 49380За pg_statio_user_indexes двете налични колони за данни са „idx_blks_read“ и „idx_blks_hit“, представляващи броя на блоковете, прочетени от диск и от памет.
Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книгаКакво можем да направим с тези данни?
Бъдете креативни! Ако заявките към конкретна таблица изглеждат изключително бавни, проследете нейната активност във времето, вижте колко последователни сканирания получава спрямо индексни сканирания, вижте дали отива на диск или памет за данните.
Ако голяма маса продължава да се прахосва често автоматично, проследявайте живите до мъртвите кортежи с течение на времето, може би специално се нуждае от автоматично вакуумиране, за да бъде настроено, за да може да завърши по-бързо, или дори може би таблицата е кандидат за разделяне.
Тъй като можем да видим кога данните идват от диск или памет, можем да създадем съотношение памет към диск с течение на времето, като определим дали в даден момент съотношението намалява през деня.
Обемът на таблиците, които обхванахме, премина през големите нападатели, основните данни, които е полезно да знаете за вътрешната работа на базите данни. В системния каталог обаче има много повече таблици, които съдържат полезни за ситуацията данни. Четенето на други таблици, както преди, ще ви помогне да получите представа за здравето на базата данни като цяло.
За повече информация относно всякакви таблици или изгледи в каталога на PostgreSQL, посетете официалната документация тук, както и информация за събирача на статистически данни тук.
