Какви показатели за внедряването на PostgreSQL трябва да наблюдавате? Тази серия от публикации в блога има за цел да предостави минимален, начален набор от основни действия за наблюдение, които трябва да приложите, за да гарантирате здравето и стабилността на вашите Postgres сървъри.
Това е третата и последна част от поредица от блогове и обхваща показатели на ниво таблица, индекс и система. Първите еднопокрити метрики на ниво клъстер и вторите еднопокрити метрики на ниво база данни.
Ниво на таблица
Обикновено данните в база данни следват правилото 80-20. 20% от таблиците съдържат повечето данни и са достъпни или мутирани най-много. Задаването на допълнителен мониторинг само за тези таблици може да предостави прозрения, които са важни, но с малък обем.
Ето някои показатели на ниво таблица, които си струва да разгледате:
1. Размер на таблица
Трябва да се следи действителният размер на диска, използван от таблицата. В повечето случаи таблицата продължава да расте, така че темпът на растеж е по-интересен.
Често се случва темпът на растеж да се промени след пускането на нова версия на приложението или основна промяна в моделите на трафик/зареждане/вход на самото приложение. Такива промени трябва да бъдат проучени, поне за да се провери дали новата скорост е устойчива от предоставения хардуер.
Действие:Следете увеличаването на размера на таблицата през всяка седмица/месец, проучвайте резки промени.
Как да:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Подуване на маса
Поради MVCC архитектурата на Postgres, по-старите версии на редовете се намират във файловете с физически данни за всяка таблица и се наричат раздуване . Операцията за изчистване на остарели версии на ред се нарича вакуум . Postgres изпълнява фонов процес, наречен autovacuum , който събира таблици кандидати (въз основа на конфигурируеми параметри) и ги изчиства вместо вас.
Bloat забавя операциите с таблицата и губи дисково пространство и може да избяга дори при автоматично вакуумиране. Изисква се наблюдение на раздуването, като абсолютен брой байтове, както и като процент (от мъртвите данни към общите данни).
Този показател може да се наблюдава или на ниво отделна таблица, или като обобщен в избрани таблици, или на ниво база данни.
Действие:Непрекъснато следете раздуването на таблицата като байтове и проценти, предупреждавайте, ако стойностите надвишават зададен праг, ВАКУУМАЙТЕ, ако е необходимо.
Как да:
Използвайте check_postgres orpgmetrics, за да получите приблизителни оценки. Вижте thewiki за повече информация.
3. Последователно сканиране
Когато се изпълняват заявки, които не използват оптимално наличните индекси, или ако статистическата информация, свързана с таблица, е твърде остаряла, Postgres може да се наложи да премине през всеки ред от таблицата. Това се нарича последователно сканиране , и не е много желателно в общия случай. Това, което би било по-добре да имате, е сканиране на индекс , където редовете на таблица са достъпни непряко чрез търсене в индекс.
PostgreSQL може да ви каже колко пъти една таблица е сканирана последователно и колко пъти е използван индекс. Можете да използвате това, за да наблюдавате или броя на последователните сканирания (ако искате да ги избегнете напълно), или като процент от общия брой сканирания.
Действие:Непрекъснато следете сек. брой сканирания или процент, предупреждение, ако стойността надвиши зададен праг.
Как да:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Ниво на индекса
1. Размер на индекс
Индексите могат да заемат значително дисково пространство. Всеки индекс на таблица може сам по себе си потенциално да има толкова дисков отпечатък, колкото самата таблица. Полезно е да следите общия размер на индексите в база данни или индексите на важни таблици, особено при внедряване, където индексите могат да бъдат създадени чрез автоматични процеси.
Неоправдано големи индекси могат да се дължат на раздуване или просто на лошо проектиран индекс. И в двата случая коригирането на причината (или чрез повторно изграждане на индекса, или чрез рефакториране на заявката/индекса) може да доведе до по-бързо време на заявка, така че си струва да се изследват големи индекси.
Действие:Следете общия размер на интересните индекси през всяка седмица/месец, проучвайте, когато са неоправдано големи.
Как да:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Подуване на индекса
Индексите също могат да се раздуят. Има твърде много фактори, включително натоварване на таблицата, тип индекс, версия на Postgres и други, които решават колко раздут индексът ще стане. Раздутите индекси могат да забавят вмъкването и да намалят ефективността на търсене. Следете набъбването на индексите както като абсолютна стойност (брой байтове), така и като процент. Индексите ще трябва да бъдат възстановени, когато станат твърде раздути.
Действие:Непрекъснато следете раздуването на индекса като байтове и проценти, предупреждавайте, ако стойностите надхвърлят зададен праг.
Как да:
Използвайте check_postgres orpgmetrics, за да получите приблизителни оценки. Вижте thewiki за повече информация.
3. Съотношение на попадане в кеша
PostgreSQL кешира често достъпни региони на индекси (а също и таблици) в паметта. Ако сте настроили заявките си да не докосват таблиците, освен за извличане на редове, следващата стъпка е да осигурите максимална устойчивост на кеша за онези важни индекси, които наистина ускоряват вашите заявки.
Използването на кеша на индекс може да се измери чрез коефициента на попадане в кеша, който е процентът на блоковете от индекса, които са били прочетени от кеша, спрямо общия брой прочетени блокове.
Действие:Непрекъснато следете процента на попадане в кеша, предупреждавайте, ако стойността падне под зададен праг. Изследвайте ниски стойности за важни индекси.
Как да:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Системно ниво
Освен метриките на PostgreSQL, важно е да следите и няколко метрики на машината или виртуалната машина, на която използвате вашия Postgres. Можете да използвате всяко популярно решение за наблюдение за това или дори да ги вземете и проследите сами.
1. Използвана памет
Съвременните Linux системи имат сложно отчитане на паметта. Препоръчваме да наблюдавате „използваната памет“, която е паметта, останала след отчитане на паметта, маркирана катосвободна , като буфери , като кеширана , и като плоча . Буферите и кеша ще отстъпят под натиск, както и повечето (обикновено над 95%) от плочата.
Използваната памет обаче трябва да се измерва за подходящо дълъг период от време. Ако имате пакетни задачи, отчети, ETL и т.н., които се изпълняват през уикендите, тогава периодът ще бъде една седмица. Истинският показател, който ще трябва да наблюдавате, е максимално използваната памет за този период.
Обикновено, когато размерът на вашата база данни расте, тази стойност има тенденция да пълзи нагоре. Ще трябва да се уверите, че максималното използване на паметта е в рамките на удобен лимит на наличната памет, като да речем 60-80%. Пренебрегването на това ще доведе до неуспех на работните ви натоварвания за анализи/OLAP поради липса на памет.
Действие:Наблюдавайте максимално използваната памет за една седмица/за нощ, предупреждавайте, ако надхвърли зададен праг, повторна настройка.
Как да :
Използваната памет се дава от MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , където Mem* полетата са от /proc/meminfo . За повече информация вижте тази статия на RedHat.
2. Средно натоварване
Простата средна стойност на натоварването все още е най-лесният и бърз начин за оценка на натоварването на сървър. Това е особено вярно за сървърите на Postgres, тъй като всеки бекенд е отделен процес на ОС и наличието на повече от тях в състояние, което може да се изпълнява, ще увеличи средната стойност на натоварването.
За даден Postgres сървър средното натоварване трябва да остане в разумен диапазон за бизнес цикъл (като една седмица, включително изпълнение на пакетни задания).
Действие:Следете средното максимално натоварване за всеки ден/седмица, проучвайте нарастващите тенденции.
Как да :
Средните стойности за зареждане за 1 минута, 5 и 15 минути са първите 3 полета от първия ред във файла /proc/loadavg .
3. Свободно дисково пространство
Последният елемент в нашия списък е най-очевидният елемент за наблюдение:количеството свободно дисково пространство във всяка файлова система, използвана от вашия PostgreSQL сървър, включително пространства за таблици, WAL файлови директории, резервни директории и регистрационни файлове на сървъра. В случаите, когато твърде много (100 милиони) файлове се създават в една файлова система, уверете се, че броят на безплатните inode също се наблюдава. Липсата на inodes също се отчита като малко дисково пространство.
Действие:Непрекъснато следете свободното дисково пространство и използването на inode във всички подходящи файлови системи, предупреждавайте, ако стойностите паднат под зададен праг.
Как да :
Свободното дисково пространство във файлова система не може да бъде извлечено директно чрез четене на всеки файл в /proc . Можете да използвате stat -f /path/to/mount или дори df за да разберете използваното, свободно и запазено дисково пространство за конкретна монтирана файлова система.
Кратка справка
Ето пълен списък на всички показатели, които сме обсъдили досега в тази серия. Не забравяйте, че това са само минималният, най-същественият набор от показатели, които трябва да наблюдавате, за да откриете кога нещата са на път да се объркат с внедряването на PostgreSQL.
Ниво на клъстер
- Обхват на идентификатора на транзакцията
- Брой бекендове
- Неактивни слотове за репликация
- Бекенд, чакащ заключване
- Бекенд неактивен в транзакция
- Закъснение при репликация за активни връзки
- Закъснение при репликация за слотове за репликация
- Брой на WAL файлове
- Брой готови за архивиране WAL файлове
Ниво на базата данни
- Свързани клиенти
- Размер
- Раздуване на масата на всички маси
- Надуване на индекси във всички индекси
- Дълго текущи транзакции
- Застой
- Най-старият вакуум
- Най-старият анализ
Ниво на таблица
- Размер на таблицата
- Раздуване на маса
- Последователно сканиране
Ниво на индекса
- Размер на индекса
- Надуване на индекса
- Съотношение на попадане в кеша
Системно ниво
- Използвана памет
- Средно зареждане
- Свободно дисково пространство
Събиране на тези показатели
Разделите по-горе предоставят SQL изрази за извличане на необходимите показатели от работещ Postgres сървър. Ако предпочитате да не пишете сами скриптовете, разгледайте инструмента с отворен код pgmetrics. Той може да събира показателите по-горе и други и да ги отчита в текстови и JSON формати.
Можете директно да изпращате отчетите за pgmetrics до нашето търговско предложение, pgDash, което съхранява и обработва тези отчети, за да показва графики и да извършва сигнали.
