ProHoster > Блог > администрация > Мониторинг на производителността на PostgreSQL заявки. Част 1 - докладване

Мониторинг на производителността на PostgreSQL заявки. Част 1 - докладване

Инженер – в превод от латински – вдъхновен.
Един инженер може всичко. в) Р. Дизел.
Епиграфи.
Мониторинг на производителността на PostgreSQL заявки. Част 1 - докладване
Или история за това защо един администратор на база данни трябва да си спомня миналото си на програмиране.

предговор

Всички имена са сменени. Съвпаденията са случайни. Материалът е само лично мнение на автора.

Отказ от гаранции: в планираната поредица от статии няма да има подробно и точно описание на използваните таблици и скриптове. Материалите не могат да бъдат използвани незабавно „КАКТО СА“.
Първо, поради голямото количество материал,
второ, поради остротата с производствената база на реален клиент.
Следователно в статиите ще бъдат дадени само идеи и описания в най-обща форма.
Може би в бъдеще системата ще нарасне до нивото на публикуване в GitHub или може би не. Времето ще покаже.

Началото на историята -Спомняте ли си как започна всичко".
Какво се случи в резултат, най-общо казано - "Синтезът като един от методите за подобряване на производителността на PostgreSQL»

Защо ми трябва всичко това?

Е, първо, за да не забравите себе си, спомняйки си славните дни в пенсия.
Второ, да систематизирам написаното. Аз самият понякога започвам да се обърквам и да забравям отделни части.

Е, и най-важното - изведнъж може да бъде полезно за някого и да помогне да не преоткрива колелото и да не събира рейк. С други думи, подобрете кармата си (не Хабровски). Защото най-ценното нещо на този свят са идеите. Основното нещо е да намерите идея. И да се превърне идеята в реалност вече е чисто технически въпрос.

Така че да започнем бавно...

Изложение на проблема.

На разположение:

PostgreSQL(10.5), смесено натоварване (OLTP+DSS), средно до леко натоварване, хоствано в AWS облака.
Няма мониторинг на база данни, мониторингът на инфраструктурата е представен като стандартни AWS инструменти в минимална конфигурация.

Изисква се:

Наблюдавайте производителността и състоянието на базата данни, намирайте и разполагайте с първоначална информация, за да оптимизирате тежките заявки към базата данни.

Кратко въведение или анализ на решенията

Като начало, нека се опитаме да анализираме възможностите за решаване на проблема от гледна точка на сравнителен анализ на ползите и проблемите за инженера и нека тези, които трябва да бъдат в списъка на персонала, да се справят с ползите и загубите на управлението.

Вариант 1 - "Работа при поискване"

Оставяме всичко както си е. Ако клиентът не е доволен от нещо в здравето, производителността на базата данни или приложението, той ще уведоми инженерите на DBA по имейл или чрез създаване на инцидент в кутията за билети.
Инженерът, след като получи известие, ще разбере проблема, ще предложи решение или ще отложи проблема, надявайки се, че всичко ще се разреши от само себе си и така или иначе всичко скоро ще бъде забравено.
Меденки и понички, синини и подутиниМеденки и понички:
1. Нищо допълнително за правене
2. Винаги има възможност да се измъкнете и да се изцапате.
3. Много време, което можете да прекарате сами.
Синини и подутини:
1. Рано или късно клиентът ще се замисли за същността на битието и универсалната справедливост в този свят и отново ще си зададе въпроса - защо им плащам парите си? Последиците винаги са едни и същи – въпросът е само кога клиентът се отегчи и му помаха за довиждане. И хранилката е празна. Това е тъжно.
2. Развитието на един инженер е нулево.
3. Трудности при планирането на работата и натоварването

Вариант 2 - „Танцувайте с тамбури, облечете и обуйте обувки“

Параграф 1-Защо ни трябва система за мониторинг, ние ще получим всички заявки. Стартираме куп всякакви заявки към речника на данните и динамични изгледи, включваме всякакви броячи, въвеждаме всичко в таблици, периодично анализираме списъци и таблици, така да се каже. В резултат на това имаме красиви или не много графики, таблици, отчети. Основното нещо - това би било повече, повече.
Параграф 2-Генерирайте активност - изпълнете анализа на всичко това.
Параграф 3-Ние подготвяме определен документ, наричаме този документ, просто - "как да оборудваме базата данни".
Параграф 4- Клиентът, виждайки цялото това великолепие от графики и фигури, е в детска наивна увереност - сега всичко ще работи за нас, скоро. И лесно и безболезнено се разделят с финансовите си средства. Ръководството също е сигурно, че нашите инженери работят усилено. Максимално натоварване.
Параграф 5- Повтаряйте стъпка 1 редовно.
Меденки и понички, синини и подутиниМеденки и понички:
1. Животът на мениджърите и инженерите е прост, предвидим и изпълнен с активност. Всичко жужи, всички са заети.
2. Животът на клиента също не е лош - той винаги е сигурен, че трябва да сте малко търпеливи и всичко ще се получи. Не се подобрява, добре, добре - този свят е несправедлив, в следващия живот - късмет.
Синини и подутини:
1. Рано или късно ще има по-умен доставчик на подобна услуга, който ще направи същото, но малко по-евтино. И ако резултатът е същият, защо да плащате повече. Което отново ще доведе до изчезването на хранилката.
2. Скучно е. Колко скучно е всяко малко смислено занимание.
3. Както в предишната версия - без развитие. Но за инженер минусът е, че за разлика от първия вариант, тук трябва постоянно да генерирате IDB. А това отнема време. Които могат да бъдат изразходвани в полза на любимия човек. Защото не можете да се грижите за себе си, всички се грижат за вас.

Вариант 3-Няма нужда да измисляте велосипед, трябва да го купите и да го карате.

Инженери от други компании съзнателно ядат пица с бира (о, славните времена на Санкт Петербург през 90-те години). Нека използваме системи за мониторинг, които са направени, дебъгвани и работещи и най-общо казано носят ползи (е, поне на създателите си).
Меденки и понички, синини и подутиниМеденки и понички:
1. Няма нужда да губите време в измисляне на това, което вече е измислено. Вземете и използвайте.
2. Системите за мониторинг не се пишат от глупаци и разбира се са полезни.
3. Работещите системи за наблюдение обикновено предоставят полезна филтрирана информация.
Синини и подутини:
1. Инженерът в случая не е инженер, а просто потребител на чужд продукт.Или потребител.
2. Клиентът трябва да бъде убеден в необходимостта да купи нещо, което той по принцип не иска да разбере и не трябва, и като цяло бюджетът за годината е одобрен и няма да се променя. След това трябва да разпределите отделен ресурс, да го конфигурирате за конкретна система. Тези. Първо трябва да плащате, плащате и пак плащате. А клиентът е скъперник. Това е нормата на този живот.

Какво да правим, Чернишевски? Въпросът ви е много уместен. (със)

В този конкретен случай и настоящата ситуация можете да направите малко по-различно - нека направим наша собствена система за наблюдение.
Мониторинг на производителността на PostgreSQL заявки. Част 1 - докладване
Е, не е система, разбира се, в пълния смисъл на думата, това е твърде гръмко и самонадеяно, но поне някак си улеснете себе си и съберете повече информация за решаване на инциденти с ефективността. За да не се окажете в ситуация - „отидете там, не знам къде, намерете това, не знам какво“.

Какви са плюсовете и минусите на този вариант:

плюсове:
1. Интересно е. Е, поне по-интересно от постоянното "свиване на файла с данни, промяна на таблично пространство и т.н."
2. Това са нови умения и ново развитие. Което в бъдеще рано или късно ще даде заслужени меденки и понички.
против:
1. Трябва да работя. Работя много.
2. Ще трябва редовно да обяснявате значението и перспективите на всяка дейност.
3. Ще трябва да се пожертва нещо, защото единственият ресурс, с който разполага инженерът – времето – е ограничено от Вселената.
4. Най-лошото и най-неприятното - в резултат на това може да се получи боклук като "Не мишка, не жаба, а непознато животно".

Който не рискува нещо не пие шампанско.
И така, забавлението започва.

Обща идея - схематично

Мониторинг на производителността на PostgreSQL заявки. Част 1 - докладване
(Илюстрация взета от статия «Синтезът като един от методите за подобряване на производителността на PostgreSQL»)

Обяснение:

  • Целевата база данни е инсталирана със стандартното PostgreSQL разширение „pg_stat_statements“.
  • В базата данни за мониторинг създаваме набор от сервизни таблици за съхраняване на историята на pg_stat_statements в началния етап и за конфигуриране на показатели и мониторинг в бъдеще
  • На хоста за наблюдение създаваме набор от bash скриптове, включително тези за генериране на инциденти в тикет системата.

Сервизни маси

Като начало, схематично опростено ERD, какво се случи в крайна сметка:
Мониторинг на производителността на PostgreSQL заявки. Част 1 - докладване
Кратко описание на таблицитекрайна точка - хост, точка на свързване към екземпляра
база данни - опции за база данни
pg_stat_history - историческа таблица за съхраняване на временни моментни снимки на изгледа pg_stat_statements на целевата база данни
metric_glosary - Речник на показателите за ефективност
metric_config - конфигурация на индивидуалните показатели
метричен - конкретна метрика за заявката, която се наблюдава
metric_alert_history - история на предупрежденията за ефективност
log_query - сервизна таблица за съхраняване на анализирани записи от лог файла на PostgreSQL, изтеглен от AWS
изходно ниво - параметри на периода от време, използван като база
контролно-пропускателен пункт - конфигурация на метрики за проверка на състоянието на базата данни
checkpoint_alert_history - история на предупреждения за показателите за проверка на състоянието на базата данни
pg_stat_db_queries — сервизна таблица на активните заявки
Дневник дейност — служебна таблица на регистъра на дейностите
trap_oid - таблица за обслужване на конфигурация на прихващане

Етап 1 - събиране на статистически данни за ефективността и получаване на отчети

Таблица се използва за съхраняване на статистическа информация. pg_stat_history
структура на таблицата pg_stat_history

                                          Таблица "public.pg_stat_history" Колона | тип | Модификатори--------------------+-------------------- --+---- -------------------------------- идентификатор | цяло число | not null default nextval('pg_stat_history_id_seq'::regclass) snapshot_timestamp | клеймо без часова зона | база_данни_id | цяло число | dbid | оид | идентификатор на потребителя | оид | queryid | bigint | заявка | текст | обаждания | bigint | общо_време | двойна точност | мин_време | двойна точност | максимално_време | двойна точност | средно_време | двойна точност | stddev_time | двойна точност | редове | bigint | shared_blks_hit | bigint | shared_blks_read | bigint | shared_blks_dirtied | bigint | shared_blks_written | bigint | local_blks_hit | bigint | local_blks_read | bigint | local_blks_dirtied | bigint | local_blks_written | bigint | temp_blks_read | bigint | temp_blks_written | bigint | blk_read_time | двойна точност | blk_write_time | двойна точност | базов_идентификатор | цяло число | Индекси: "pg_stat_history_pkey" ПЪРВИЧЕН КЛЮЧ, btree (id) "database_idx" btree (database_id) "queryid_idx" btree (queryid) "snapshot_timestamp_idx" btree (snapshot_timestamp) Ограничения на външен ключ: "database_id_fk" ВЪНШЕН КЛЮЧ (database_ id) РЕФЕРЕНЦИИ база данни (id ) ПРИ ИЗТРИВАНЕ НА КАСКАДА

Както можете да видите, таблицата е само кумулативен изглед на данни pg_stat_statements в целевата база данни.

Използването на тази таблица е много просто.

pg_stat_history ще представлява натрупаната статистика за изпълнение на заявка за всеки час. В началото на всеки час, след попълване на таблицата, статистика pg_stat_statements нулиране с pg_stat_statements_reset().
Забележка: статистика се събира за заявки с продължителност над 1 секунда.
Попълване на таблицата pg_stat_history

--pg_stat_history.sql
CREATE OR REPLACE FUNCTION pg_stat_history( ) RETURNS boolean AS $$
DECLARE
  endpoint_rec record ;
  database_rec record ;
  pg_stat_snapshot record ;
  current_snapshot_timestamp timestamp without time zone;
BEGIN
  current_snapshot_timestamp = date_trunc('minute',now());  
  
  FOR endpoint_rec IN SELECT * FROM endpoint 
  LOOP
    FOR database_rec IN SELECT * FROM database WHERE endpoint_id = endpoint_rec.id 
	  LOOP
	    
		RAISE NOTICE 'NEW SHAPSHOT IS CREATING';
		
		--Connect to the target DB	  
	    EXECUTE 'SELECT dblink_connect(''LINK1'',''host='||endpoint_rec.host||' dbname='||database_rec.name||' user=USER password=PASSWORD '')';
 
        RAISE NOTICE 'host % and dbname % ',endpoint_rec.host,database_rec.name;
		RAISE NOTICE 'Creating snapshot of pg_stat_statements for database %',database_rec.name;
		
		SELECT 
	      *
		INTO 
		  pg_stat_snapshot
	    FROM dblink('LINK1',
	      'SELECT 
	       dbid , SUM(calls),SUM(total_time),SUM(rows) ,SUM(shared_blks_hit) ,SUM(shared_blks_read) ,SUM(shared_blks_dirtied) ,SUM(shared_blks_written) , 
           SUM(local_blks_hit) , SUM(local_blks_read) , SUM(local_blks_dirtied) , SUM(local_blks_written) , SUM(temp_blks_read) , SUM(temp_blks_written) , SUM(blk_read_time) , SUM(blk_write_time)
	       FROM pg_stat_statements WHERE dbid=(SELECT oid from pg_database where datname=current_database() ) 
		   GROUP BY dbid
  	      '
	               )
	      AS t
	       ( dbid oid , calls bigint , 
  	         total_time double precision , 
	         rows bigint , shared_blks_hit bigint , shared_blks_read bigint ,shared_blks_dirtied bigint ,shared_blks_written	 bigint ,
             local_blks_hit	 bigint ,local_blks_read bigint , local_blks_dirtied bigint ,local_blks_written bigint ,
             temp_blks_read	 bigint ,temp_blks_written bigint ,
             blk_read_time double precision , blk_write_time double precision	  
	       );
		 
		INSERT INTO pg_stat_history
          ( 
		    snapshot_timestamp  ,database_id  ,
			dbid , calls  ,total_time ,
            rows ,shared_blks_hit  ,shared_blks_read  ,shared_blks_dirtied  ,shared_blks_written ,local_blks_hit , 	 	
            local_blks_read,local_blks_dirtied,local_blks_written,temp_blks_read,temp_blks_written, 	
            blk_read_time, blk_write_time 
		  )		  
	    VALUES
	      (
	       current_snapshot_timestamp ,
		   database_rec.id ,
	       pg_stat_snapshot.dbid ,pg_stat_snapshot.calls,
	       pg_stat_snapshot.total_time,
	       pg_stat_snapshot.rows ,pg_stat_snapshot.shared_blks_hit ,pg_stat_snapshot.shared_blks_read ,pg_stat_snapshot.shared_blks_dirtied ,pg_stat_snapshot.shared_blks_written , 
           pg_stat_snapshot.local_blks_hit , pg_stat_snapshot.local_blks_read , pg_stat_snapshot.local_blks_dirtied , pg_stat_snapshot.local_blks_written , 
	       pg_stat_snapshot.temp_blks_read , pg_stat_snapshot.temp_blks_written , pg_stat_snapshot.blk_read_time , pg_stat_snapshot.blk_write_time 	   
	      );		   
		  
        RAISE NOTICE 'Creating snapshot of pg_stat_statements for queries with min_time more than 1000ms';
	
        FOR pg_stat_snapshot IN
          --All queries with max_time greater than 1000 ms
	      SELECT 
	        *
	      FROM dblink('LINK1',
	        'SELECT 
	         dbid , userid ,queryid,query,calls,total_time,min_time ,max_time,mean_time, stddev_time ,rows ,shared_blks_hit ,
			 shared_blks_read ,shared_blks_dirtied ,shared_blks_written , 
             local_blks_hit , local_blks_read , local_blks_dirtied , 
			 local_blks_written , temp_blks_read , temp_blks_written , blk_read_time , 
			 blk_write_time
	         FROM pg_stat_statements 
			 WHERE dbid=(SELECT oid from pg_database where datname=current_database() AND min_time >= 1000 ) 
  	        '

	                  )
	        AS t
	         ( dbid oid , userid oid , queryid bigint ,query text , calls bigint , 
  	           total_time double precision ,min_time double precision	 ,max_time double precision	 , mean_time double precision	 ,  stddev_time double precision	 , 
	           rows bigint , shared_blks_hit bigint , shared_blks_read bigint ,shared_blks_dirtied bigint ,shared_blks_written	 bigint ,
               local_blks_hit	 bigint ,local_blks_read bigint , local_blks_dirtied bigint ,local_blks_written bigint ,
               temp_blks_read	 bigint ,temp_blks_written bigint ,
               blk_read_time double precision , blk_write_time double precision	  
	         )
	    LOOP
		  INSERT INTO pg_stat_history
          ( 
		    snapshot_timestamp  ,database_id  ,
			dbid ,userid  , queryid  , query  , calls  ,total_time ,min_time ,max_time ,mean_time ,stddev_time ,
            rows ,shared_blks_hit  ,shared_blks_read  ,shared_blks_dirtied  ,shared_blks_written ,local_blks_hit , 	 	
            local_blks_read,local_blks_dirtied,local_blks_written,temp_blks_read,temp_blks_written, 	
            blk_read_time, blk_write_time 
		  )		  
	      VALUES
	      (
	       current_snapshot_timestamp ,
		   database_rec.id ,
	       pg_stat_snapshot.dbid ,pg_stat_snapshot.userid ,pg_stat_snapshot.queryid,pg_stat_snapshot.query,pg_stat_snapshot.calls,
	       pg_stat_snapshot.total_time,pg_stat_snapshot.min_time ,pg_stat_snapshot.max_time,pg_stat_snapshot.mean_time, pg_stat_snapshot.stddev_time ,
	       pg_stat_snapshot.rows ,pg_stat_snapshot.shared_blks_hit ,pg_stat_snapshot.shared_blks_read ,pg_stat_snapshot.shared_blks_dirtied ,pg_stat_snapshot.shared_blks_written , 
           pg_stat_snapshot.local_blks_hit , pg_stat_snapshot.local_blks_read , pg_stat_snapshot.local_blks_dirtied , pg_stat_snapshot.local_blks_written , 
	       pg_stat_snapshot.temp_blks_read , pg_stat_snapshot.temp_blks_written , pg_stat_snapshot.blk_read_time , pg_stat_snapshot.blk_write_time 	   
	      );
		  
        END LOOP;

        PERFORM dblink_disconnect('LINK1');  
				
	  END LOOP ;--FOR database_rec IN SELECT * FROM database WHERE endpoint_id = endpoint_rec.id 
    
  END LOOP;

RETURN TRUE;  
END
$$ LANGUAGE plpgsql;

В резултат на това след определен период от време в табл pg_stat_history ще имаме набор от моментни снимки на съдържанието на таблицата pg_stat_statements целева база данни.

Всъщност докладване

Използвайки прости заявки, можете да получите доста полезни и интересни отчети.

Обобщени данни за даден период от време

разследване

SELECT 
  database_id , 
  SUM(calls) AS calls ,SUM(total_time)  AS total_time ,
  SUM(rows) AS rows , SUM(shared_blks_hit)  AS shared_blks_hit,
  SUM(shared_blks_read) AS shared_blks_read ,
  SUM(shared_blks_dirtied) AS shared_blks_dirtied,
  SUM(shared_blks_written) AS shared_blks_written , 
  SUM(local_blks_hit) AS local_blks_hit , 
  SUM(local_blks_read) AS local_blks_read , 
  SUM(local_blks_dirtied) AS local_blks_dirtied , 
  SUM(local_blks_written)  AS local_blks_written,
  SUM(temp_blks_read) AS temp_blks_read, 
  SUM(temp_blks_written) temp_blks_written , 
  SUM(blk_read_time) AS blk_read_time , 
  SUM(blk_write_time) AS blk_write_time
FROM 
  pg_stat_history
WHERE 
  queryid IS NULL AND
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT
GROUP BY database_id ;

D.B. Време

to_char(интервал '1 милисекунда' * pg_total_stat_history_rec.total_time, 'HH24:MI:SS.MS')

I/O време

to_char(интервал '1 милисекунда' * ( pg_total_stat_history_rec.blk_read_time + pg_total_stat_history_rec.blk_write_time), 'HH24:MI:SS.MS')

ТОП10 SQL по total_time

разследване

SELECT 
  queryid , 
  SUM(calls) AS calls ,
  SUM(total_time)  AS total_time  	
FROM 
  pg_stat_history
WHERE 
  queryid IS NOT NULL AND 
  database_id = DATABASE_ID AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT 
GROUP BY queryid 
ORDER BY 3 DESC 
LIMIT 10
-------------------------------------------------- ------------------------------------ | ТОП10 SQL ПО ОБЩО ВРЕМЕ НА ИЗПЪЛНЕНИЕ | #| queryid| обаждания| извиква %| общо_време (ms) | dbtime % +----+-----------+-----------+-----------+------ --------------------+---------- | 1| 821760255| 2| .00001|00:03:23.141( 203141.681 ms.)| 5.42 | 2| 4152624390| 2| .00001|00:03:13.929( 193929.215 ms.)| 5.17 | 3| 1484454471| 4| .00001|00:02:09.129( 129129.057 ms.)| 3.44 | 4| 655729273| 1| .00000|00:02:01.869( 121869.981 ms.)| 3.25 | 5| 2460318461| 1| .00000|00:01:33.113( 93113.835 ms.)| 2.48 | 6| 2194493487| 4| .00001|00:00:17.377( 17377.868 ms.)| .46 | 7| 1053044345| 1| .00000|00:00:06.156( 6156.352 ms.)| .16 | 8| 3644780286| 1| .00000|00:00:01.063( 1063.830 ms.)| .03

TOP10 SQL по общо I/O време

разследване

SELECT 
  queryid , 
  SUM(calls) AS calls ,
  SUM(blk_read_time + blk_write_time)  AS io_time
FROM 
  pg_stat_history
WHERE 
  queryid IS NOT NULL AND 
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT
GROUP BY  queryid 
ORDER BY 3 DESC 
LIMIT 10
-------------------------------------------------- ------------------------------------- | ТОП10 SQL ПО ОБЩО I/O ВРЕМЕ | #| queryid| обаждания| извиква %| I/O време (ms)|db I/O време % +----+----------+-----------+------ -----+--------------------------------+----------- -- | 1| 4152624390| 2| .00001|00:08:31.616( 511616.592 ms.)| 31.06 юни | 2| 821760255| 2| .00001|00:08:27.099( 507099.036 ms.)| 30.78 | 3| 655729273| 1| .00000|00:05:02.209( 302209.137 ms.)| 18.35 | 4| 2460318461| 1| .00000|00:04:05.981( 245981.117 ms.)| 14.93 | 5| 1484454471| 4| .00001|00:00:39.144( 39144.221 ms.)| 2.38 | 6| 2194493487| 4| .00001|00:00:18.182( 18182.816 ms.)| 1.10 | 7| 1053044345| 1| .00000|00:00:16.611( 16611.722 ms.)| 1.01 | 8| 3644780286| 1| .00000|00:00:00.436( 436.205 ms.)| .03

TOP10 SQL по максимално време на изпълнение

разследване

SELECT 
  id AS snapshotid , 
  queryid , 
  snapshot_timestamp ,  
  max_time 
FROM 
  pg_stat_history 
WHERE 
  queryid IS NOT NULL AND 
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT
ORDER BY 4 DESC 
LIMIT 10

-------------------------------------------------- ------------------------------------ | TOP10 SQL ПО МАКСИМАЛНО ВРЕМЕ НА ИЗПЪЛНЕНИЕ | #| моментна снимка| snapshotID| queryid| max_time (ms) +----+-----------------+----------+--------- --+---------------------------------------- | 1| 05.04.2019 г. 01:03 ч.| 4169| 655729273| 00:02:01.869( 121869.981 ms.) | 2| 04.04.2019 17:00| 4153| 821760255| 00:01:41.570( 101570.841 ms.) | 3| 04.04.2019 г. 16:00| 4146| 821760255| 00:01:41.570( 101570.841 ms.) | 4| 04.04.2019 г. 16:00| 4144| 4152624390| 00:01:36.964( 96964.607 ms.) | 5| 04.04.2019 17:00| 4151| 4152624390| 00:01:36.964( 96964.607 ms.) | 6| 05.04.2019 г. 10:00 | 4188| 1484454471| 00:01:33.452( 93452.150 ms.) | 7| 04.04.2019 17:00| 4150| 2460318461| 00:01:33.113( 93113.835 ms.) | 8| 04.04.2019 15:00| 4140| 1484454471| 00:00:11.892 (11892.302 ms.) | 9| 04.04.2019 г. 16:00| 4145| 1484454471| 00:00:11.892 (11892.302 ms.) | 10| 04.04.2019 17:00| 4152| 1484454471| 00:00:11.892 (11892.302 ms.)

TOP10 SQL от SHARED буфер за четене/запис

разследване

SELECT 
  id AS snapshotid , 
  queryid ,
  snapshot_timestamp , 
  shared_blks_read , 
  shared_blks_written 
FROM 
  pg_stat_history
WHERE 
  queryid IS NOT NULL AND 
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT AND
  ( shared_blks_read > 0 OR shared_blks_written > 0 )
ORDER BY 4 DESC  , 5 DESC 
LIMIT 10
-------------------------------------------------- ------------------------------------ | ТОП10 SQL ОТ СПОДЕЛЕНИ БУФЕРИ ЗА ЧЕТЕНЕ/ЗАПИС | #| моментна снимка| snapshotID| queryid| прочетени споделени блокове| споделени блокове запис +----+------------------+-----------+---------- -+--------------------+-------------------- | 1| 04.04.2019 17:00| 4153| 821760255| 797308| 0 | 2| 04.04.2019 г. 16:00| 4146| 821760255| 797308| 0 | 3| 05.04.2019 г. 01:03 ч.| 4169| 655729273| 797158| 0 | 4| 04.04.2019 г. 16:00| 4144| 4152624390| 756514| 0 | 5| 04.04.2019 17:00| 4151| 4152624390| 756514| 0 | 6| 04.04.2019 17:00| 4150| 2460318461| 734117| 0 | 7| 04.04.2019 17:00| 4155| 3644780286| 52973| 0 | 8| 05.04.2019 г. 01:03 ч.| 4168| 1053044345| 52818| 0 | 9| 04.04.2019 15:00| 4141| 2194493487| 52813| 0 | 10| 04.04.2019 г. 16:00| 4147| 2194493487| 52813| 0 -------------------------------------------------- --------------------------------------------------

Хистограма на разпределението на заявките по максимално време за изпълнение

искания

SELECT  
  MIN(max_time) AS hist_min  , 
  MAX(max_time) AS hist_max , 
  (( MAX(max_time) - MIN(min_time) ) / hist_columns ) as hist_width
FROM 
  pg_stat_history 
WHERE 
  queryid IS NOT NULL AND
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT ;

SELECT 
  SUM(calls) AS calls
FROM 
  pg_stat_history 
WHERE 
  queryid IS NOT NULL AND
  database_id =DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT AND 
  ( max_time >= hist_current_min AND  max_time < hist_current_max ) ;

|------------------------------------------------ ---------------------------------------------- | MAX_TIME ХИСТОГРАМА | ОБЩО ОБАЖДАНИЯ: 33851920 | МИН. ВРЕМЕ: 00:00:01.063 | МАКСИМАЛНО ВРЕМЕ: 00:02:01.869 ---------------------------------- -------- ---------------------------- | мин. продължителност| максимална продължителност| обаждания +---------------------------------+------------- ---------------------+---------- | 00:00:01.063( 1063.830 ms.) | 00:00:13.144 (13144.445 ms.) | 9 | 00:00:13.144 (13144.445 ms.) | 00:00:25.225( 25225.060 ms.) | 0 | 00:00:25.225( 25225.060 ms.) | 00:00:37.305( 37305.675 ms.) | 0 | 00:00:37.305( 37305.675 ms.) | 00:00:49.386( 49386.290 ms.) | 0 | 00:00:49.386( 49386.290 ms.) | 00:01:01.466( 61466.906 ms.) | 0 | 00:01:01.466( 61466.906 ms.) | 00:01:13.547( 73547.521 ms.) | 0 | 00:01:13.547( 73547.521 ms.) | 00:01:25.628( 85628.136 ms.) | 0 | 00:01:25.628( 85628.136 ms.) | 00:01:37.708( 97708.751 ms.) | 4 | 00:01:37.708( 97708.751 ms.) | 00:01:49.789 (109789.366 ms.) | 2 | 00:01:49.789 (109789.366 ms.) | 00:02:01.869( 121869.981 ms.) | 0

ТОП10 моментни снимки по заявка за секунда

искания

--pg_qps.sql
--Calculate Query Per Second 
CREATE OR REPLACE FUNCTION pg_qps( pg_stat_history_id integer ) RETURNS double precision AS $$
DECLARE
 pg_stat_history_rec record ;
 prev_pg_stat_history_id integer ;
 prev_pg_stat_history_rec record;
 total_seconds double precision ;
 result double precision;
BEGIN 
  result = 0 ;
  
  SELECT *
  INTO pg_stat_history_rec
  FROM 
    pg_stat_history
  WHERE id = pg_stat_history_id ;

  IF pg_stat_history_rec.snapshot_timestamp IS NULL 
  THEN
    RAISE EXCEPTION 'ERROR - Not found pg_stat_history for id = %',pg_stat_history_id;
  END IF ;  
  
 --RAISE NOTICE 'pg_stat_history_id = % , snapshot_timestamp = %', pg_stat_history_id , 
 pg_stat_history_rec.snapshot_timestamp ;
  
  SELECT 
    MAX(id)   
  INTO
    prev_pg_stat_history_id
  FROM
    pg_stat_history
  WHERE 
    database_id = pg_stat_history_rec.database_id AND
	queryid IS NULL AND
	id < pg_stat_history_rec.id ;

  IF prev_pg_stat_history_id IS NULL 
  THEN
    RAISE NOTICE 'Not found previous pg_stat_history shapshot for id = %',pg_stat_history_id;
	RETURN NULL ;
  END IF;
  
  SELECT *
  INTO prev_pg_stat_history_rec
  FROM 
    pg_stat_history
  WHERE id = prev_pg_stat_history_id ;
  
  --RAISE NOTICE 'prev_pg_stat_history_id = % , prev_snapshot_timestamp = %', prev_pg_stat_history_id , prev_pg_stat_history_rec.snapshot_timestamp ;    

  total_seconds = extract(epoch from ( pg_stat_history_rec.snapshot_timestamp - prev_pg_stat_history_rec.snapshot_timestamp ));
  
  --RAISE NOTICE 'total_seconds = % ', total_seconds ;    
  
  --RAISE NOTICE 'calls = % ', pg_stat_history_rec.calls ;      
  
  IF total_seconds > 0 
  THEN
    result = pg_stat_history_rec.calls / total_seconds ;
  ELSE
   result = 0 ; 
  END IF;
   
 RETURN result ;
END
$$ LANGUAGE plpgsql;


SELECT 
  id , 
  snapshot_timestamp ,
  calls , 	
  total_time , 
  ( select pg_qps( id )) AS QPS ,
  blk_read_time ,
  blk_write_time
FROM 
  pg_stat_history
WHERE 
  queryid IS NULL AND 
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT AND
  ( select pg_qps( id )) IS NOT NULL 
ORDER BY 5 DESC 
LIMIT 10

|------------------------------------------------ ---------------------------------------------- | ТОП10 моментни снимки, подредени по числа на QueryPerSeconds -------------------------------------- ------ -------------------------------------------- ------ -------------------------------------------- | #| моментна снимка| snapshotID| обаждания| общо dbtime| QPS | I/O време | I/O време % +-----+-----------------+-----------+------- ----+---------------------------------+---------- -+--------------------------------+----------- | 1| 04.04.2019 г. 20:04| 4161| 5758631| 00:06:30.513( 390513.926 ms.)| 1573.396| 00:00:01.470( 1470.110 ms.)| .376 | 2| 04.04.2019 17:00| 4149| 3529197| 00:11:48.830( 708830.618 ms.)| 980.332| 00:12:47.834( 767834.052 ms.)| 108.324 | 3| 04.04.2019 г. 16:00| 4143| 3525360| 00:10:13.492( 613492.351 ms.)| 979.267| 00:08:41.396( 521396.555 ms.)| 84.988 4 | 04.04.2019| 21 г. 03:4163| 2781536| 00| 03:06.470:186470.979( 785.745 ms.)| 00| 00:00.249:249.865 (134 ms.)| .5 | 04.04.2019| 19 03:4159| 2890362| 00| 03:16.784:196784.755( 776.979 ms.)| 00| 00:01.441:1441.386( 732 ms.)| .6 | 04.04.2019| 14 г. 00:4137| 2397326| 00| 04:43.033:283033.854( 665.924 ms.)| 00| 00:00.024:24.505(009 ms.)| .7 | 04.04.2019| 15 00:4139| 2394416| 00| 04:51.435:291435.010( 665.116 ms.)| 00| 00:12.025:12025.895( 4.126 ms.)| 8 | 04.04.2019| 13 00:4135 | 2373043| 00| 04:26.791:266791.988( 659.179 ms.)| 00| 00:00.064:64.261(024 ms.)| .9 | 05.04.2019| 01 г. 03:4167 ч.| 4387191| 00| 06:51.380:411380.293( 609.332 ms.)| 00| 05:18.847:318847.407( 77.507 ms.)| 10 | 04.04.2019| 18 г. 01:4157| 1145596| 00| 01:19.217:79217.372( 313.004 ms.)| 00 00| 01.319:1319.676:1.666( XNUMX ms.)| XNUMX

Почасова история на изпълнение с QueryPerSeconds и I/O време

разследване

SELECT 
  id , 
  snapshot_timestamp ,
  calls , 	
  total_time , 
  ( select pg_qps( id )) AS QPS ,
  blk_read_time ,
  blk_write_time
FROM 
  pg_stat_history
WHERE 
  queryid IS NULL AND 
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT
ORDER BY 2

|-----------------------------------------------------------------------------------------------
| HOURLY EXECUTION HISTORY  WITH QueryPerSeconds and I/O Time
-----------------------------------------------------------------------------------------------------------------------------------------------
| QUERY PER SECOND HISTORY
|    #|          snapshot| snapshotID|      calls|                      total dbtime|        QPS|                          I/O time| I/O time %
+-----+------------------+-----------+-----------+----------------------------------+-----------+----------------------------------+-----------
|    1|  04.04.2019 11:00|       4131|       3747|  00:00:00.835(       835.374 ms.)|      1.041|  00:00:00.000(          .000 ms.)|       .000
|    2|  04.04.2019 12:00|       4133|    1002722|  00:01:52.419(    112419.376 ms.)|    278.534|  00:00:00.149(       149.105 ms.)|       .133
|    3|  04.04.2019 13:00|       4135|    2373043|  00:04:26.791(    266791.988 ms.)|    659.179|  00:00:00.064(        64.261 ms.)|       .024
|    4|  04.04.2019 14:00|       4137|    2397326|  00:04:43.033(    283033.854 ms.)|    665.924|  00:00:00.024(        24.505 ms.)|       .009
|    5|  04.04.2019 15:00|       4139|    2394416|  00:04:51.435(    291435.010 ms.)|    665.116|  00:00:12.025(     12025.895 ms.)|      4.126
|    6|  04.04.2019 16:00|       4143|    3525360|  00:10:13.492(    613492.351 ms.)|    979.267|  00:08:41.396(    521396.555 ms.)|     84.988
|    7|  04.04.2019 17:00|       4149|    3529197|  00:11:48.830(    708830.618 ms.)|    980.332|  00:12:47.834(    767834.052 ms.)|    108.324
|    8|  04.04.2019 18:01|       4157|    1145596|  00:01:19.217(     79217.372 ms.)|    313.004|  00:00:01.319(      1319.676 ms.)|      1.666
|    9|  04.04.2019 19:03|       4159|    2890362|  00:03:16.784(    196784.755 ms.)|    776.979|  00:00:01.441(      1441.386 ms.)|       .732
|   10|  04.04.2019 20:04|       4161|    5758631|  00:06:30.513(    390513.926 ms.)|   1573.396|  00:00:01.470(      1470.110 ms.)|       .376
|   11|  04.04.2019 21:03|       4163|    2781536|  00:03:06.470(    186470.979 ms.)|    785.745|  00:00:00.249(       249.865 ms.)|       .134
|   12|  04.04.2019 23:03|       4165|    1443155|  00:01:34.467(     94467.539 ms.)|    200.438|  00:00:00.015(        15.287 ms.)|       .016
|   13|  05.04.2019 01:03|       4167|    4387191|  00:06:51.380(    411380.293 ms.)|    609.332|  00:05:18.847(    318847.407 ms.)|     77.507
|   14|  05.04.2019 02:03|       4171|     189852|  00:00:10.989(     10989.899 ms.)|     52.737|  00:00:00.539(       539.110 ms.)|      4.906
|   15|  05.04.2019 03:01|       4173|       3627|  00:00:00.103(       103.000 ms.)|      1.042|  00:00:00.004(         4.131 ms.)|      4.010
|   16|  05.04.2019 04:00|       4175|       3627|  00:00:00.085(        85.235 ms.)|      1.025|  00:00:00.003(         3.811 ms.)|      4.471
|   17|  05.04.2019 05:00|       4177|       3747|  00:00:00.849(       849.454 ms.)|      1.041|  00:00:00.006(         6.124 ms.)|       .721
|   18|  05.04.2019 06:00|       4179|       3747|  00:00:00.849(       849.561 ms.)|      1.041|  00:00:00.000(          .051 ms.)|       .006
|   19|  05.04.2019 07:00|       4181|       3747|  00:00:00.839(       839.416 ms.)|      1.041|  00:00:00.000(          .062 ms.)|       .007
|   20|  05.04.2019 08:00|       4183|       3747|  00:00:00.846(       846.382 ms.)|      1.041|  00:00:00.000(          .007 ms.)|       .001
|   21|  05.04.2019 09:00|       4185|       3747|  00:00:00.855(       855.426 ms.)|      1.041|  00:00:00.000(          .065 ms.)|       .008
|   22|  05.04.2019 10:00|       4187|       3797|  00:01:40.150(    100150.165 ms.)|      1.055|  00:00:21.845(     21845.217 ms.)|     21.812

Текст на всички SQL избрани

разследване

SELECT 
  queryid , 
  query 
FROM 
  pg_stat_history
WHERE 
  queryid IS NOT NULL AND 
  database_id = DATABASE_ID  AND
  snapshot_timestamp BETWEEN BEGIN_TIMEPOINT AND END_TIMEPOINT
GROUP BY queryid , query

Общо

Както можете да видите, с доста прости средства можете да получите много полезна информация за натоварването и състоянието на базата данни.

Забележка:Ако коригирате queryid в заявките, тогава ще получим историята за отделна заявка (за да спестим място, отчетите за отделна заявка са пропуснати).

Така че статистическите данни за ефективността на заявките са налични и се събират.
Първият етап „събиране на статистически данни” е завършен.

Можете да продължите към втория етап - "конфигуриране на показатели за ефективност".
Мониторинг на производителността на PostgreSQL заявки. Част 1 - докладване

Но това е съвсем различна история.

За да се продължи ...

Източник: www.habr.com

Добавяне на нов коментар