ProHoster > Blog > administration > Ydeevneovervågning af PostgreSQL-forespørgsler. Del 1 - rapportering

Ydeevneovervågning af PostgreSQL-forespørgsler. Del 1 - rapportering

Ingeniør - oversat fra latin - inspireret.
En ingeniør kan alt. (c) R. Diesel.
Epigrafier.
Ydeevneovervågning af PostgreSQL-forespørgsler. Del 1 - rapportering
Eller en historie om, hvorfor en databaseadministrator skal huske sin programmeringsfortid.

Forord

Alle navne er blevet ændret. Kampe er tilfældige. Materialet er udelukkende forfatterens personlige mening.

Fraskrivelse af garantier: i den planlagte serie af artikler vil der ikke være nogen detaljeret og præcis beskrivelse af de anvendte tabeller og scripts. Materialer kan ikke umiddelbart bruges "SOM DE ER".
For det første på grund af den store mængde materiale,
for det andet på grund af skarpheden med en reel kundes produktionsgrundlag.
Derfor vil kun ideer og beskrivelser i den mest generelle form blive givet i artiklerne.
Måske vil systemet i fremtiden vokse til niveauet for opslag på GitHub, eller måske ikke. Tiden vil vise.

Begyndelsen af ​​historien-Kan du huske, hvordan det hele begyndte'.
Hvad skete der som et resultat, i de mest generelle vendinger - "Syntese som en af ​​metoderne til at forbedre PostgreSQL-ydeevnen»

Hvorfor har jeg brug for alt dette?

Nå, for det første, for ikke at glemme dig selv, huske de herlige dage i pension.
For det andet at systematisere det skrevne. For allerede mig selv begynder jeg nogle gange at blive forvirret og glemme separate dele.

Nå, og vigtigst af alt - pludselig kan det være nyttigt for nogen og hjælpe med ikke at genopfinde hjulet og ikke at samle en rive. Med andre ord, forbedre din karma (ikke Khabrovsky). For det mest værdifulde i denne verden er ideer. Det vigtigste er at finde en idé. Og at omsætte ideen til virkelighed er allerede et rent teknisk spørgsmål.

Så lad os starte langsomt...

Formulering af problemet.

Ledig:

PostgreSQL(10.5), blandet belastning (OLTP+DSS), medium til let belastning, hostet i AWS-skyen.
Der er ingen databaseovervågning, infrastrukturovervågning præsenteres som standard AWS-værktøjer i en minimal konfiguration.

kræver:

Overvåg databasens ydeevne og status, find og hav indledende information for at optimere tunge databaseforespørgsler.

Kort introduktion eller analyse af løsninger

Til at begynde med, lad os prøve at analysere mulighederne for at løse problemet ud fra en sammenlignende analyse af fordele og problemer for ingeniøren, og lad dem, der formodes at være på personalelisten, tage sig af fordelene og tabene af ledelsen.

Mulighed 1 - "Arbejder efter behov"

Vi lader alt være som det er. Hvis kunden ikke er tilfreds med noget i databasens eller applikationens helbred, ydeevne, vil han underrette DBA-ingeniørerne via e-mail eller ved at oprette en hændelse i billetboksen.
En ingeniør, der har modtaget en meddelelse, vil forstå problemet, tilbyde en løsning eller skrinlægge problemet i håb om, at alt vil løse sig selv, og alligevel vil alt snart blive glemt.
Honningkager og donuts, blå mærker og knopperHonningkager og donuts:
1. Intet ekstra at gøre
2. Der er altid mulighed for at komme ud og blive snavset.
3. Meget tid, som du kan bruge på egen hånd.
Blå mærker og knopper:
1. Før eller siden vil kunden tænke på essensen af ​​væren og universel retfærdighed i denne verden og igen stille sig selv spørgsmålet - hvorfor betaler jeg dem mine penge? Konsekvensen er altid den samme – spørgsmålet er kun, hvornår kunden keder sig og vinkede farvel. Og foderautomaten er tom. Det er trist.
2. Udviklingen af ​​en ingeniør er nul.
3. Vanskeligheder med at planlægge arbejde og læsse

Mulighed 2 - "Dans med tamburiner, tag sko på og på"

Afsnit 1-Hvorfor har vi brug for et overvågningssystem, vi modtager alle henvendelser. Vi lancerer en masse alle mulige forespørgsler til dataordbogen og dynamiske visninger, tænder for alle mulige tællere, bringer alt i tabeller, analyserer med jævne mellemrum lister og tabeller, som det var. Som et resultat har vi smukke eller ikke særlig grafer, tabeller, rapporter. Det vigtigste - det ville være mere, mere.
Afsnit 2-Generer aktivitet - kør analysen af ​​alt dette.
Afsnit 3-Vi er ved at forberede et bestemt dokument, vi kalder dette dokument, simpelthen - "hvordan udstyrer vi databasen."
Afsnit 4- Kunden, der ser al denne pragt af grafer og figurer, er i en barnlig naiv tillid - nu vil alt fungere for os, snart. Og skiller sig nemt og smertefrit af med deres økonomiske ressourcer. Ledelsen er også sikker på, at vores ingeniører arbejder hårdt. Max belastning.
Afsnit 5- Gentag trin 1 regelmæssigt.
Honningkager og donuts, blå mærker og knopperHonningkager og donuts:
1. Livet for ledere og ingeniører er enkelt, forudsigeligt og fyldt med aktivitet. Alt summer, alle har travlt.
2. Kundens liv er heller ikke dårligt - han er altid sikker på, at du skal være lidt tålmodig, og alt ordner sig. Det bliver ikke bedre, jamen - denne verden er uretfærdig, i det næste liv - heldig.
Blå mærker og knopper:
1. Før eller siden vil der være en smartere udbyder af en lignende service, der vil gøre det samme, men lidt billigere. Og hvis resultatet er det samme, hvorfor betale mere. Hvilket igen vil føre til, at foderautomaten forsvinder.
2. Det er kedeligt. Hvor kedeligt enhver lille meningsfuld aktivitet.
3. Som i den tidligere version - ingen udvikling. Men for en ingeniør er minuset, at du i modsætning til den første mulighed her konstant skal generere en IDB. Og det tager tid. Som kan bruges til gavn for din elskede. For du kan ikke passe på dig selv, alle bekymrer sig om dig.

Mulighed 3-Ingen grund til at opfinde en cykel, du skal købe den og køre på den.

Ingeniører fra andre virksomheder spiser bevidst pizza med øl (åh, Skt. Petersborgs glorværdige tider i 90'erne). Lad os bruge overvågningssystemer, der er lavet, fejlrettet og fungerer, og generelt giver de fordele (vel, i det mindste for deres skabere).
Honningkager og donuts, blå mærker og knopperHonningkager og donuts:
1. Ingen grund til at spilde tid på at opfinde det, der allerede er opfundet. Tag og brug.
2. Overvågningssystemer er ikke skrevet af tåber, og selvfølgelig er de nyttige.
3. Fungerende overvågningssystemer giver normalt nyttig filtreret information.
Blå mærker og knopper:
1. Ingeniøren i dette tilfælde er ikke en ingeniør, men blot en bruger af en andens produkt, eller en bruger.
2. Kunden skal være overbevist om behovet for at købe noget, som han generelt ikke ønsker at forstå, og det skal han ikke, og generelt er budgettet for året godkendt og vil ikke ændre sig. Derefter skal du allokere en separat ressource, konfigurere den til et specifikt system. De der. Først skal du betale, betale og betale igen. Og kunden er nærig. Dette er normen i dette liv.

Hvad skal man gøre, Chernyshevsky? Dit spørgsmål er meget relevant. (Med)

I dette særlige tilfælde og den nuværende situation kan du gøre lidt anderledes - lad os lave vores eget overvågningssystem.
Ydeevneovervågning af PostgreSQL-forespørgsler. Del 1 - rapportering
Nå, ikke et system, selvfølgelig, i ordets fulde betydning, det er for højt og formastigt, men gør det i det mindste på en eller anden måde lettere for dig selv og indsamle mere information for at løse præstationshændelser. For ikke at finde dig selv i en situation - "gå derhen, jeg ved ikke hvor, find det, jeg ved ikke hvad."

Hvad er fordele og ulemper ved denne mulighed:

Teknikere:
1. Det er interessant. Nå, i det mindste mere interessant end den konstante "shrink datafile, change tablespace, etc."
2. Det er nye færdigheder og ny udvikling. Som i fremtiden før eller siden vil give velfortjente honningkager og donuts.
Ulemper:
1. Skal arbejde. Arbejd meget.
2. Du bliver regelmæssigt nødt til at forklare betydningen og perspektiverne af al aktivitet.
3. Noget skal ofres, fordi den eneste ressource, der er tilgængelig for ingeniøren - tiden - er begrænset af Universet.
4. Det værste og mest ubehagelige - som følge heraf kan affald som "Ikke en mus, ikke en frø, men et ukendt lille dyr" vise sig.

Hvem der ikke risikerer noget, drikker ikke champagne.
Så det sjove begynder.

Generel idé - skematisk

Ydeevneovervågning af PostgreSQL-forespørgsler. Del 1 - rapportering
(Illustration taget fra artiklen «Syntese som en af ​​metoderne til at forbedre PostgreSQL-ydeevnen")

forklaring:

  • Måldatabasen er installeret med standard PostgreSQL-udvidelsen "pg_stat_statements".
  • I overvågningsdatabasen opretter vi et sæt servicetabeller for at gemme pg_stat_statements-historikken på det indledende stadium og for at konfigurere metrics og overvågning i fremtiden
  • På overvågningsværten opretter vi et sæt bash-scripts, inklusive dem til at generere hændelser i billetsystemet.

Service tabeller

Til at begynde med, en skematisk forenklet ERD, hvad der skete i sidste ende:
Ydeevneovervågning af PostgreSQL-forespørgsler. Del 1 - rapportering
Kort beskrivelse af tabellerneendpoint - vært, forbindelsespunkt til instansen
database - database muligheder
pg_stat_historie - historisk tabel til lagring af midlertidige snapshots af pg_stat_statements-visningen af ​​måldatabasen
metrisk_ordliste - Ordbog over præstationsmålinger
metric_config - konfiguration af individuelle målinger
metrisk - en specifik metric for den anmodning, der overvåges
metric_alert_history - historie om ydeevneadvarsler
log_forespørgsel - servicetabel til lagring af parsede poster fra PostgreSQL-logfilen downloadet fra AWS
baseline - parametre for den tidsperiode, der bruges som basis
kontrolpost - konfiguration af metrikker til kontrol af databasens status
checkpoint_alert_history - advarselshistorik for kontrolmålinger for databasestatus
pg_stat_db_queries — servicetabel over aktive anmodninger
aktivitetslog — aktivitetslogtjenestetabel
trap_oid - trap konfiguration service tabel

Trin 1 - indsaml præstationsstatistik og få rapporter

En tabel bruges til at gemme statistisk information. pg_stat_historie
pg_stat_historie tabelstruktur

                                          Tabel "public.pg_stat_history" Kolonne | type | Modifikatorer----------------------+---------------------- --+---- ---------------------------------- id | heltal | ikke null standard nextval('pg_stat_history_id_seq'::regclass) snapshot_timestamp | tidsstempel uden tidszone | database_id | heltal | dbid | oid | brugerid | oid | queryid | bigint | forespørgsel | tekst | opkald | bigint | total_tid | dobbelt præcision | min_tid | dobbelt præcision | max_tid | dobbelt præcision | middeltid | dobbelt præcision | stddev_tid | dobbelt præcision | rækker | bigint | shared_blks_hit | bigint | shared_blks_read | bigint | shared_blks_dirtied | bigint | delt_blks_skrevet | 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_læsetid | dobbelt præcision | blk_skrivetid | dobbelt præcision | baseline_id | heltal | Indekser: "pg_stat_history_pkey" PRIMÆR NØGLE, btree (id) "database_idx" btree (database_id) "queryid_idx" btree (queryid) "snapshot_timestamp_idx" btree (snapshot_timestamp) Fremmednøgle begrænsninger: "database_id) KEYk" (database_id) KEYk" (database_id) KEYk" ) PÅ SLET CASCADE

Som du kan se, er tabellen kun en kumulativ visningsdata pg_stat_statements i måldatabasen.

Brugen af ​​denne tabel er meget enkel.

pg_stat_historie vil repræsentere den akkumulerede statistik for udførelse af forespørgsler for hver time. I begyndelsen af ​​hver time, efter at have udfyldt tabellen, statistik pg_stat_statements nulstilles med pg_stat_statements_reset().
Note: Der indsamles statistik for anmodninger med en varighed på mere end 1 sekund.
Udfylder tabellen 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;

Som et resultat, efter en vis periode i tabellen pg_stat_historie vi vil have et sæt snapshots af indholdet af tabellen pg_stat_statements måldatabase.

Faktisk rapportering

Ved hjælp af simple forespørgsler kan du få ganske nyttige og interessante rapporter.

Aggregerede data for en given periode

Forespørgsel

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. Tid

to_char(interval '1 millisekund' * pg_total_stat_history_rec.total_time, 'HH24:MI:SS.MS')

I/O-tid

to_char(interval '1 millisekund' * ( pg_total_stat_history_rec.blk_read_time + pg_total_stat_history_rec.blk_write_time ), 'HH24:MI:SS.MS')

TOP10 SQL ved total_time

Forespørgsel

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
-------------------------------------------------- ------------------------------------ | TOP10 SQL EFTER SAMLET UDFØRELSESTID | #| queryid| opkald| opkald total_tid (ms) | dbtid % +----+------------------------+----- --------------------+---------- | 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 efter samlet I/O-tid

Forespørgsel

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
-------------------------------------------------- -------------------------------------------- | TOP10 SQL EFTER SAMLET I/O-TID | #| queryid| opkald| opkald I/O-tid (ms)|db I/O-tid % +----+------------+----------+------ -----+--------------------------------+----------- -- | 1| 4152624390| 2| .00001|00:08:31.616( 511616.592 ms.)| 31.06. juni | 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 efter maks. tidspunkt for udførelse

Forespørgsel

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 VED MAKS UDFØRELSESTID | #| øjebliksbillede| snapshotID| queryid| max_time (ms) +----+--------------------- --+---------------------------------------- | 1| 05.04.2019/01/03 4169:655729273| 00| 02| 01.869:121869.981:2( 04.04.2019 ms.) | 17| 00/4153/821760255 00:01| 41.570| 101570.841| 3:04.04.2019:16( 00 ms.) | 4146| 821760255/00/01 41.570:101570.841| 4| 04.04.2019| 16:00:4144( 4152624390 ms.) | 00| 01/36.964/96964.607 5:04.04.2019| 17| 00| 4151:4152624390:00( 01 ms.) | 36.964| 96964.607/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:8( 04.04.2019 ms.) | 15| 00/4140/1484454471 00:00| 11.892| 11892.302| 9:04.04.2019:16( 00 ms.) | 4145| 1484454471/00/00 11.892:11892.302| 10| 04.04.2019| 17:00:4152( 1484454471 ms.) | 00| 00/11.892/11892.302 XNUMX:XNUMX| XNUMX| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.) | XNUMX| XNUMX/XNUMX/XNUMX XNUMX:XNUMX| XNUMX| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.)

TOP10 SQL af SHARED buffer læse/skrive

Forespørgsel

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
-------------------------------------------------- ------------------------------------ | TOP10 SQL VED DELT BUFFER LÆS/SKRIV | #| øjebliksbillede| snapshotID| queryid| delte blokke læst| delte blokke skriv +----+-------------------+-----------+----- --+---------------------------+---------------------------- | 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 | XNUMX| XNUMX/XNUMX/XNUMX XNUMX:XNUMX| XNUMX| XNUMX| XNUMX| XNUMX | XNUMX| XNUMX/XNUMX/XNUMX XNUMX:XNUMX| XNUMX| XNUMX| XNUMX| XNUMX -------------------------------------------------- --------------------------------------------------

Histogram over forespørgselsfordeling efter maksimal udførelsestid

anmodninger

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 HISTOGRAM | SAMLET OPKALD : 33851920 | MIN TID : 00:00:01.063 | MAKS TID : 00:02:01.869 ------------------------------------------ ---------------------------- | min varighed| max varighed| ringer +----------------------------------+------- ----------------------+---------- | 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

TOP10 Snapshots efter forespørgsel pr. sekund

anmodninger

--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

|------------------------------------------------ ------------------------------------------ | TOP10 Snapshots sorteret efter QueryPerSeconds-tal -------------------------------------------- ------ -------------------------------------------- ------ -------------------------------------------------- | #| øjebliksbillede| snapshotID| opkald| samlet dbtid| QPS | I/O tid | I/O-tid % +-----+------------------------+-----------+------- ----+-----------------------------------+---------- --+----------------------------------------+----------- | 1| 04.04.2019/20/04 4161:5758631| 00| 06| 30.513:390513.926:1573.396( 00 ms.)| 00| 01.470:1470.110:376( 2 ms.)| .04.04.2019 | 17| 00/4149/3529197 00:11| 48.830| 708830.618| 980.332:00:12( 47.834 ms.)| 767834.052| 108.324:3:04.04.2019( 16 ms.)| 00 | 4143| 3525360/00/10 13.492:613492.351| 979.267| 00| 08:41.396:521396.555( 84.988 ms.)| 4| 04.04.2019:21:03( 4163 ms.)| 2781536 | 00| 03/06.470/186470.979 785.745:00| 00| 00.249| 249.865:134:5( 04.04.2019 ms.)| 19| 03:4159:2890362( 00 ms.)| .03 | 16.784| 196784.755/776.979/00 00:01.441| 1441.386| 732| 6:04.04.2019:14( 00 ms.)| 4137| 2397326:00:04( 43.033 ms.)| .283033.854 | 665.924| 00/00/00.024 24.505:009 | 7| 04.04.2019| 15:00:4139( 2394416 ms.)| 00| 04:51.435:291435.010( 665.116 ms.)| .00 | 00| 12.025/12025.895/4.126 8:04.04.2019| 13| 00| 4135:2373043:00( 04 ms.)| 26.791| 266791.988:659.179:00( 00 ms.)| 00.064 | 64.261| 024/9/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 | 10| 04.04.2019/18/01 4157:1145596| 00| 01| 19.217:79217.372:313.004( 00 ms.)| 00| 01.319:1319.676:1.666( XNUMX ms.)| XNUMX | XNUMX| XNUMX/XNUMX/XNUMX XNUMX:XNUMX| XNUMX| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.)| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.)| XNUMX

Timelig eksekveringshistorik med QueryPerSeconds og I/O-tid

Forespørgsel

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

Tekst af alle SQL-valg

Forespørgsel

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

Total

Som du kan se, kan du med ret enkle midler få en masse nyttig information om arbejdsbyrden og databasens tilstand.

Bemærk:Hvis du retter queryid'et i forespørgslerne, så får vi historikken for en separat anmodning (for at spare plads udelades rapporter for en separat anmodning).

Så statistiske data om forespørgselsydeevne er tilgængelige og indsamlet.
Den første fase "indsamling af statistiske data" er afsluttet.

Du kan gå videre til anden fase - "konfiguration af præstationsmålinger".
Ydeevneovervågning af PostgreSQL-forespørgsler. Del 1 - rapportering

Men det er en anden historie.

Fortsættes ...

Kilde: www.habr.com

Tilføj en kommentar