ProHoster > Log > administrasjon > Ytelsesovervåking av PostgreSQL-spørringer. Del 1 - rapportering

Ytelsesovervåking av PostgreSQL-spørringer. Del 1 - rapportering

Ingeniør – oversatt fra latin – inspirert.
En ingeniør kan gjøre alt. (c) R. Diesel.
Epigrafer.
Ytelsesovervåking av PostgreSQL-spørringer. Del 1 - rapportering
Eller en historie om hvorfor en databaseadministrator trenger å huske programmeringsfortiden sin.

Forord

Alle navn er endret. Kamper er tilfeldige. Materialet er utelukkende forfatterens personlige mening.

Fraskrivelse av garantier: i den planlagte artikkelserien vil det ikke være noen detaljert og nøyaktig beskrivelse av tabellene og skriptene som brukes. Materialer kan ikke umiddelbart brukes "AS IS".
For det første, på grunn av den store mengden materiale,
for det andre på grunn av skarpheten med produksjonsbasen til en ekte kunde.
Derfor vil kun ideer og beskrivelser i den mest generelle formen bli gitt i artiklene.
Kanskje systemet i fremtiden vil vokse til nivået for innlegg på GitHub, eller kanskje ikke. Tiden vil vise.

Begynnelsen av historien-Husker du hvordan det hele begynte'.
Hva skjedde som et resultat, i de mest generelle termer - "Syntese som en av metodene for å forbedre PostgreSQL-ytelsen»

Hvorfor trenger jeg alt dette?

Vel, for det første, for ikke å glemme deg selv, huske de strålende dagene i pensjonisttilværelsen.
For det andre å systematisere det som ble skrevet. For allerede meg selv, noen ganger begynner jeg å bli forvirret og glemme separate deler.

Vel, og viktigst av alt - plutselig kan det komme godt med for noen og hjelpe å ikke finne opp hjulet på nytt og ikke samle en rake. Med andre ord, forbedre karmaen din (ikke Khabrovsky). For det mest verdifulle i denne verden er ideer. Det viktigste er å finne en idé. Og å omsette ideen til virkelighet er allerede et rent teknisk problem.

Så la oss starte sakte...

Formulering av problemet.

Tilgjengelig:

PostgreSQL(10.5), blandet belastning (OLTP+DSS), middels til lett belastning, vert i AWS-skyen.
Det er ingen databaseovervåking, infrastrukturovervåking presenteres som standard AWS-verktøy i en minimal konfigurasjon.

krever:

Overvåk ytelsen og statusen til databasen, finn og ha innledende informasjon for å optimalisere tunge databasespørringer.

Kort introduksjon eller analyse av løsninger

Til å begynne med, la oss prøve å analysere alternativene for å løse problemet fra synspunktet til en komparativ analyse av fordelene og problemene for ingeniøren, og la de som er ment å være på personallisten håndtere fordelene og tapene til ledelsen.

Alternativ 1 - "Jobber på forespørsel"

Vi lar alt være som det er. Dersom kunden ikke er fornøyd med noe i helsen, ytelsen til databasen eller applikasjonen, vil han varsle DBA-ingeniørene på e-post eller ved å opprette en hendelse i billettboksen.
En ingeniør, etter å ha mottatt et varsel, vil forstå problemet, tilby en løsning eller skrinlegge problemet, i håp om at alt vil løse seg selv, og uansett vil alt snart bli glemt.
Pepperkaker og smultringer, blåmerker og støtPepperkaker og smultringer:
1. Ikke noe ekstra å gjøre
2. Det er alltid mulighet for å komme seg ut og bli skitten.
3. Mye tid som du kan bruke på egen hånd.
Blåmerker og støt:
1. Før eller siden vil kunden tenke på essensen av å være og universell rettferdighet i denne verden og igjen stille seg selv spørsmålet - hvorfor betaler jeg dem pengene mine? Konsekvensen er alltid den samme – spørsmålet er bare når kunden kjeder seg og vinket farvel. Og materen er tom. Det er trist.
2. Utviklingen av en ingeniør er null.
3. Vansker med å planlegge arbeid og lasting

Alternativ 2 - "Dans med tamburiner, ta på og ta på sko"

Paragraf 1-Hvorfor trenger vi et overvåkingssystem, vi vil motta alle forespørsler. Vi lanserer en haug med alle slags spørringer til dataordboken og dynamiske visninger, slår på alle slags tellere, bringer alt inn i tabeller, analyserer periodisk lister og tabeller, som det var. Som et resultat har vi vakre eller lite grafer, tabeller, rapporter. Det viktigste - det ville være mer, mer.
Paragraf 2-Generer aktivitet-kjør analysen av alt dette.
Paragraf 3-Vi forbereder et bestemt dokument, vi kaller dette dokumentet, ganske enkelt - "hvordan utstyrer vi databasen."
Paragraf 4– Kunden, som ser all denne storheten av grafer og figurer, er i en barnslig naiv tillit – nå vil alt fungere for oss, snart. Og skiller seg enkelt og smertefritt med sine økonomiske ressurser. Ledelsen er også sikker på at ingeniørene våre jobber hardt. Maks lasting.
Paragraf 5- Gjenta trinn 1 regelmessig.
Pepperkaker og smultringer, blåmerker og støtPepperkaker og smultringer:
1. Livet til ledere og ingeniører er enkelt, forutsigbart og fylt med aktivitet. Alt surrer, alle er opptatt.
2. Kundens liv er heller ikke dårlig - han er alltid sikker på at du må være litt tålmodig og alt ordner seg. Det blir ikke bedre, vel, vel - denne verden er urettferdig, i det neste livet - vil du være heldig.
Blåmerker og støt:
1. Før eller siden vil det være en smartere leverandør av en lignende tjeneste som vil gjøre det samme, men litt billigere. Og hvis resultatet er det samme, hvorfor betale mer. Noe som igjen vil føre til at materen forsvinner.
2. Det er kjedelig. Hvor kjedelig enhver liten meningsfull aktivitet.
3. Som i forrige versjon - ingen utvikling. Men for en ingeniør er minuset at, i motsetning til det første alternativet, her må du hele tiden generere en IDB. Og det tar tid. Som kan brukes til fordel for din kjære. For du kan ikke ta vare på deg selv, alle bryr seg om deg.

Alternativ 3 - Du trenger ikke å finne opp en sykkel, du må kjøpe den og sykle den.

Ingeniører fra andre selskaper spiser med viten pizza med øl (å, de strålende tidene i St. Petersburg på 90-tallet). La oss bruke overvåkingssystemer som er laget, feilsøkt og fungerer, og generelt sett gir de fordeler (vel, i det minste for skaperne deres).
Pepperkaker og smultringer, blåmerker og støtPepperkaker og smultringer:
1. Ingen grunn til å kaste bort tid på å finne opp det som allerede er oppfunnet. Ta og bruk.
2. Overvåkingssystemer er ikke skrevet av idioter, og selvfølgelig er de nyttige.
3. Fungerende overvåkingssystemer gir vanligvis nyttig filtrert informasjon.
Blåmerker og støt:
1. Ingeniøren i dette tilfellet er ikke en ingeniør, men bare en bruker av en annens produkt, eller en bruker.
2. Kunden må være overbevist om behovet for å kjøpe noe han generelt ikke ønsker å forstå, og det burde han ikke, og generelt er budsjettet for året godkjent og vil ikke endres. Deretter må du tildele en egen ressurs, konfigurere den for et spesifikt system. De. Først må du betale, betale og betale igjen. Og kunden er gjerrig. Dette er normen i dette livet.

Hva skal jeg gjøre, Chernyshevsky? Spørsmålet ditt er veldig relevant. (Med)

I dette spesielle tilfellet og den nåværende situasjonen kan du gjøre litt annerledes - la oss lage vårt eget overvåkingssystem.
Ytelsesovervåking av PostgreSQL-spørringer. Del 1 - rapportering
Vel, ikke et system, selvfølgelig, i ordets fulle forstand, dette er for høyt og overmodig, men gjør det i det minste på en eller annen måte enklere for deg selv og samle inn mer informasjon for å løse ytelseshendelser. For ikke å finne deg selv i en situasjon - "gå dit, jeg vet ikke hvor, finn det, jeg vet ikke hva."

Hva er fordelene og ulempene med dette alternativet:

Pros:
1. Det er interessant. Vel, i det minste mer interessant enn den konstante "krympe datafil, endre tabellplass, etc."
2. Dette er nye ferdigheter og ny utvikling. Som i fremtiden, før eller siden, vil gi velfortjente pepperkaker og smultringer.
Cons:
1. Må jobbe. Jobbe mye.
2. Du må regelmessig forklare betydningen og perspektivene til all aktivitet.
3. Noe vil måtte ofres, fordi den eneste ressursen som er tilgjengelig for ingeniøren - tiden - er begrenset av universet.
4. Det verste og mest ubehagelige – som et resultat kan søppel som «Ikke en mus, ikke en frosk, men et ukjent lite dyr» vise seg.

Den som ikke risikerer noe drikker ikke champagne.
Så moroa begynner.

Generell idé - skjematisk

Ytelsesovervåking av PostgreSQL-spørringer. Del 1 - rapportering
(Illustrasjon hentet fra artikkelen «Syntese som en av metodene for å forbedre PostgreSQL-ytelsen")

Forklaring:

  • Måldatabasen er installert med standard PostgreSQL-utvidelse "pg_stat_statements".
  • I overvåkingsdatabasen oppretter vi et sett med tjenestetabeller for å lagre pg_stat_statements-historikken på det innledende stadiet og for å konfigurere beregninger og overvåking i fremtiden
  • På overvåkingsverten lager vi et sett med bash-skript, inkludert de for å generere hendelser i billettsystemet.

Service tabeller

Til å begynne med, en skjematisk forenklet ERD, hva som skjedde til slutt:
Ytelsesovervåking av PostgreSQL-spørringer. Del 1 - rapportering
Kort beskrivelse av tabelleneendepunkt - vert, koblingspunkt til instansen
database - databasealternativer
pg_stat_history - historisk tabell for lagring av midlertidige øyeblikksbilder av pg_stat_statements-visningen av måldatabasen
metrisk_ordliste - Ordbok over ytelsesmålinger
metric_config - konfigurasjon av individuelle beregninger
metrisk - en spesifikk beregning for forespørselen som overvåkes
metric_alert_history - historie med ytelsesvarsler
log_query - Tjenestetabell for lagring av analyserte poster fra PostgreSQL-loggfilen lastet ned fra AWS
baseline - parametere for tidsperioden brukt som base
sjekkpunkt - konfigurasjon av metrikk for å sjekke statusen til databasen
checkpoint_alert_history - advarselshistorikk for sjekkmålinger for databasestatus
pg_stat_db_queries — servicetabell over aktive forespørsler
aktivitetsloggen — aktivitetsloggtjenestetabell
trap_oid - trap konfigurasjonstjenestetabell

Trinn 1 - samle resultatstatistikk og få rapporter

En tabell brukes til å lagre statistisk informasjon. pg_stat_history
pg_stat_history tabellstruktur

                                          Tabell "public.pg_stat_history" Kolonne | skriv | Modifikatorer ----------------------+------------------------------+------------------------------------------------------------id | heltall | ikke null standard nextval('pg_stat_history_id_seq'::regclass) snapshot_timestamp | tidsstempel uten tidssone | database_id | heltall | dbid | oid | brukerid | oid | queryid | bigint | spørring | tekst | ringer | bigint | total_tid | dobbel presisjon | min_tid | dobbel presisjon | maks_tid | dobbel presisjon | mean_time | dobbel presisjon | stddev_tid | dobbel presisjon | rader | 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 | dobbel presisjon | blk_skrivetid | dobbel presisjon | baseline_id | heltall | Indekser: "pg_stat_history_pkey" Primærnøkkel, Btree (id) "Database_idx" BTREE (DATABASE_ID) "Queryid_idx" BTREE (QUERYID) "SNAPSHOT_TIMESTAMP_IDX" BTREE (Snapshotre (Snapshotre (Snapshotre (Snapshotre) (Øyeblikksbilde) Constraint_time" Foreign_time_k eign Key (Database_id) Referanser Database (ID) På Slett Cascade

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

Bruken av dette bordet er veldig enkelt.

pg_stat_history vil representere den akkumulerte statistikken for utførelse av spørringer for hver time. I begynnelsen av hver time, etter å ha fylt ut tabellen, statistikk pg_stat_statements tilbakestille med pg_stat_statements_reset().
Merk: statistikk samles inn for forespørsler med en varighet på mer enn 1 sekund.
Fyller pg_stat_history-tabellen

--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, etter en viss tidsperiode i tabellen pg_stat_history vi vil ha et sett med øyeblikksbilder av innholdet i tabellen pg_stat_statements måldatabase.

Faktisk rapportering

Ved å bruke enkle spørringer kan du få ganske nyttige og interessante rapporter.

Aggregerte data for en gitt tidsperiode

henvendelse

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(intervall '1 millisekund' * pg_total_stat_history_rec.total_time, 'HH24:MI:SS.MS')

I/O-tid

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

TOP10 SQL etter total_time

henvendelse

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 ETTER TOTAL UTFØRELSESTID | #| queryid| samtaler| samtaler total_tid (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 etter total I/O-tid

henvendelse

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 ETTER TOTAL I/U-TID | #| queryid| samtaler| ringer T-skjorte 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 etter maks tid for utførelse

henvendelse

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 ETTER MAKS UTFØRELSESTID | #| øyeblikksbilde| snapshotID| queryid| maks_tid (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 ms.) | 8| 04.04.2019/15/00 4140:1484454471| 00| 00| 11.892:11892.302:9( 04.04.2019 ms.) | 16| 00/4145/1484454471 00:00| 11.892| 11892.302| 10:04.04.2019:17( 00 ms.) | 4152| 1484454471/00/00 11.892:11892.302| XNUMX| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.) | XNUMX| XNUMX/XNUMX/XNUMX XNUMX:XNUMX| XNUMX| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.)

TOP10 SQL av DELT buffer lesing/skriving

henvendelse

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 LES/SKRIV | #| øyeblikksbilde| snapshotID| queryid| delte blokker lest| delte blokker 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 av spørringsfordeling etter maksimal utførelsestid

forespørsler

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 | TOTALT ANrop : 33851920 | MIN TID : 00:00:01.063 | MAKS TID : 00:02:01.869 ------------------------------------------------------------------------------------------ | min varighet| maks varighet| 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 øyeblikksbilder etter spørring per sekund

forespørsler

--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 Øyeblikksbilder sortert etter QueryPerSeconds-tall -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | #| øyeblikksbilde| snapshotID| samtaler| total dbtime| QPS | I/O-tid | I/O-tid % +-----+-------------------+-----+-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 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:980.332( 00 ms.)| 12| 47.834:767834.052:108.324( 3 ms.)| 04.04.2019 | 16| 00/4143/3525360 00:10| 13.492| 613492.351| 979.267:00:08( 41.396 ms.)| 521396.555| 84.988:4:04.04.2019( 21 ms.)| 03 | 4163| 2781536/00/03 06.470:186470.979| 785.745| 00| 00:00.249:249.865( 134 ms.)| 5| 04.04.2019:19:03( 4159 ms.)| .2890362 | 00| 03 16.784:196784.755| 776.979| 00| 00:01.441:1441.386( 732 ms.)| 6| 04.04.2019:14:00( 4137 ms.)| .2397326 | 00| 04 43.033:283033.854 | 665.924| 00| 00:00.024:24.505( 009 ms.)| 7| 04.04.2019:15:00( 4139 ms.)| .2394416 | 00| 04/51.435/291435.010 665.116:00| 00| 12.025| 12025.895:4.126:8( 04.04.2019 ms.)| 13| 00:4135:2373043( 00 ms.)| 04 | 26.791| 266791.988/659.179/00 00:00.064| 64.261| 024| 9:05.04.2019:01( 03 ms.)| 4167| 4387191:00:06( 51.380 ms.)| .411380.293 | 609.332| 00/05/18.847 318847.407:77.507| 10| 04.04.2019| 18:01:4157( 1145596 ms.)| 00| 01:19.217:79217.372( 313.004 ms.)| 00 | 00| 01.319 1319.676:1.666| XNUMX| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.)| XNUMX| XNUMX:XNUMX:XNUMX( XNUMX ms.)| XNUMX

Timebasert utførelseshistorikk med QueryPerSeconds og I/O-tid

henvendelse

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 av alle SQL-valg

henvendelse

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 ganske enkle midler få mye nyttig informasjon om arbeidsmengden og tilstanden til databasen.

Merk:Hvis du fikser queryid i spørringene, får vi historikken for en separat forespørsel (for å spare plass utelates rapporter for en separat forespørsel).

Så statistiske data om søkeytelse er tilgjengelig og samlet inn.
Første trinn "innsamling av statistiske data" er fullført.

Du kan gå videre til det andre trinnet - "konfigurere ytelsesberegninger".
Ytelsesovervåking av PostgreSQL-spørringer. Del 1 - rapportering

Men det er en annen historie.

To be continued ...

Kilde: www.habr.com

Legg til en kommentar