Prestatiebewaking van PostgreSQL-query's. Deel 1 - rapportage

Engineer - vertaald uit het Latijn - geïnspireerd.
Een ingenieur kan alles. (c) R.Diesel.
Opschriften.
Prestatiebewaking van PostgreSQL-query's. Deel 1 - rapportage
Of een verhaal over waarom een ​​databasebeheerder zijn programmeerverleden moet onthouden.

Voorwoord

Alle namen zijn veranderd. Wedstrijden zijn willekeurig. Het materiaal is uitsluitend de persoonlijke mening van de auteur.

Vrijwaring van garanties: in de geplande reeks artikelen zal er geen gedetailleerde en nauwkeurige beschrijving zijn van de gebruikte tabellen en scripts. Materialen kunnen niet onmiddellijk "AS IS" worden gebruikt.
Ten eerste vanwege de grote hoeveelheid materiaal,
ten tweede vanwege de scherpte met de productiebasis van een echte klant.
Daarom zullen in de artikelen alleen ideeën en beschrijvingen in de meest algemene vorm worden gegeven.
Misschien groeit het systeem in de toekomst naar het niveau van posten op GitHub, of misschien niet. De tijd zal het leren.

Begin van het verhaal-Weet je nog hoe het allemaal begon.
Wat er als resultaat gebeurde, in de meest algemene bewoordingen - "Synthese als een van de methoden om de prestaties van PostgreSQL te verbeteren»

Waarom heb ik dit allemaal nodig?

Nou, ten eerste, om jezelf niet te vergeten, denk aan de glorieuze dagen met pensioen.
Ten tweede om te systematiseren wat er is geschreven. Want ikzelf begin soms in de war te raken en losse onderdelen te vergeten.

Nou ja, en vooral - plotseling kan het iemand van pas komen en helpen om het wiel niet opnieuw uit te vinden en geen hark te verzamelen. Met andere woorden, verbeter je karma (niet Khabrovsky). Want het meest waardevolle in deze wereld zijn ideeën. Het belangrijkste is om een ​​idee te vinden. En om het idee naar de realiteit te vertalen, is al een puur technische kwestie.

Dus laten we langzaam beginnen...

Formulering van het probleem.

Verkrijgbaar:

PostgreSQL(10.5), gemengde belasting (OLTP+DSS), gemiddelde tot lichte belasting, gehost in de AWS-cloud.
Er is geen database monitoring, infrastructuur monitoring wordt gepresenteerd als standaard AWS tools in een minimale configuratie.

vereist:

Bewaak de prestaties en status van de database, vind en beschik over eerste informatie om zware databasequery's te optimaliseren.

Korte introductie of analyse van oplossingen

Laten we om te beginnen proberen de opties voor het oplossen van het probleem te analyseren vanuit het oogpunt van een vergelijkende analyse van de voordelen en problemen voor de ingenieur, en degenen die op de personeelslijst zouden moeten staan, de voordelen en verliezen laten afhandelen van beheer.

Optie 1 - "Werken op aanvraag"

We laten alles zoals het is. Als de klant niet tevreden is over iets in de gezondheid, prestaties van de database of applicatie, zal hij de DBA-engineers hiervan op de hoogte stellen via e-mail of door een incident in de ticketbox aan te maken.
Een technicus die een melding heeft ontvangen, zal het probleem begrijpen, een oplossing bieden of het probleem op de plank leggen, in de hoop dat alles vanzelf oplost en bovendien is alles snel vergeten.
Peperkoek en donuts, blauwe plekken en bultenPeperkoek en donuts:
1. Niets extra's te doen
2. Er is altijd de mogelijkheid om naar buiten te gaan en vies te worden.
3. Veel tijd die je alleen kunt besteden.
Blauwe plekken en stoten:
1. Vroeg of laat zal de klant nadenken over de essentie van het zijn en universele rechtvaardigheid in deze wereld en zichzelf opnieuw de vraag stellen: waarom betaal ik ze mijn geld? Het gevolg is altijd hetzelfde - de enige vraag is wanneer de klant zich verveelt en gedag zwaait. En de feeder is leeg. Het is zielig.
2. De ontwikkeling van een ingenieur is nul.
3. Moeilijkheden bij het plannen van werk en laden

Optie 2 - "Dans met tamboerijnen, schoenen aan en aan"

Paragraaf 1-Waarom hebben we een monitoringsysteem nodig, we zullen alle verzoeken ontvangen. We lanceren allerlei queries naar de datadictionary en dynamische views, zetten allerlei tellers aan, brengen alles in tabellen, analyseren als het ware periodiek lijsten en tabellen. Als gevolg hiervan hebben we mooie of niet erge grafieken, tabellen, rapporten. Het belangrijkste - dat zou meer zijn, meer.
Paragraaf 2- Genereer activiteit - voer de analyse van dit alles uit.
Paragraaf 3-We bereiden een bepaald document voor, we noemen dit document simpelweg - "hoe rusten we de database uit."
Paragraaf 4- De klant, die al deze pracht van grafieken en cijfers ziet, heeft een kinderlijk naïef vertrouwen - nu zal alles binnenkort voor ons werken. En gemakkelijk en pijnloos afstand doen van hun financiële middelen. Het management is er ook zeker van dat onze ingenieurs hard aan het werk zijn. Maximaal laden.
Paragraaf 5- Herhaal stap 1 regelmatig.
Peperkoek en donuts, blauwe plekken en bultenPeperkoek en donuts:
1. Het leven van managers en ingenieurs is eenvoudig, voorspelbaar en vol activiteit. Alles bruist, iedereen is druk.
2. Het leven van de klant is ook niet slecht - hij is er altijd zeker van dat je een beetje geduld moet hebben en dat alles goed komt. Niet beter worden, nou, nou - deze wereld is oneerlijk, in het volgende leven - geluk.
Blauwe plekken en stoten:
1. Vroeg of laat komt er een slimmere aanbieder van een vergelijkbare dienst die hetzelfde gaat doen, maar dan iets goedkoper. En als het resultaat hetzelfde is, waarom zou u dan meer betalen? Wat weer zal leiden tot het verdwijnen van de feeder.
2. Het is saai. Hoe saai elke kleine zinvolle activiteit.
3. Net als in de vorige versie - geen ontwikkeling. Maar voor een ingenieur is het minpunt dat je hier, in tegenstelling tot de eerste optie, constant een IDB moet genereren. En dat kost tijd. Die kan worden besteed ten behoeve van uw dierbare. Want je kunt niet voor jezelf zorgen, iedereen geeft om je.

Optie 3 - Je hoeft geen fiets uit te vinden, je moet hem kopen en erop rijden.

Ingenieurs van andere bedrijven eten willens en wetens pizza met bier (oh, de glorieuze tijden van St. Petersburg in de jaren 90). Laten we bewakingssystemen gebruiken die zijn gemaakt, gedebugd en werkend, en over het algemeen brengen ze voordelen met zich mee (tenminste voor hun makers).
Peperkoek en donuts, blauwe plekken en bultenPeperkoek en donuts:
1. U hoeft geen tijd te verspillen aan het uitvinden van wat al is uitgevonden. Neem en gebruik.
2. Monitoringsystemen zijn niet door dwazen geschreven, en natuurlijk zijn ze nuttig.
3. Werkende monitoringsystemen leveren meestal bruikbare gefilterde informatie op.
Blauwe plekken en stoten:
1. De ingenieur is in dit geval geen ingenieur, maar gewoon een gebruiker van andermans product, of een gebruiker.
2. De klant moet overtuigd zijn van de noodzaak om iets te kopen dat hij over het algemeen niet wil begrijpen, en dat zou hij ook niet moeten doen, en over het algemeen is het budget voor het jaar goedgekeurd en zal het niet veranderen. Vervolgens moet u een afzonderlijke bron toewijzen, deze configureren voor een specifiek systeem. Die. Eerst moet je betalen, betalen en nog eens betalen. En de klant is gierig. Dit is de norm van dit leven.

Wat te doen, Tsjernysjevski? Uw vraag is zeer relevant. (Met)

In dit specifieke geval en de huidige situatie kun je iets anders doen - laten we ons eigen monitoringsysteem maken.
Prestatiebewaking van PostgreSQL-query's. Deel 1 - rapportage
Nou ja, geen systeem natuurlijk, in de volle zin van het woord, dit is te luid en aanmatigend, maar maak het jezelf op de een of andere manier gemakkelijker en verzamel meer informatie om prestatie-incidenten op te lossen. Om jezelf niet in een situatie te bevinden - "ga daarheen, ik weet niet waar, vind dat, ik weet niet wat."

Wat zijn de voor- en nadelen van deze optie:

Voors:
1. Het is interessant. Nou ja, in ieder geval interessanter dan de constante "gegevensbestand verkleinen, tabelruimte wijzigen, enz."
2. Dit zijn nieuwe vaardigheden en nieuwe ontwikkeling. Wat in de toekomst vroeg of laat welverdiende ontbijtkoek en donuts zal opleveren.
Tegens:
1. Moet werken. Veel werken.
2. Je zult regelmatig de betekenis en perspectieven van alle activiteiten moeten uitleggen.
3. Er zal iets moeten worden opgeofferd, omdat de enige hulpbron waarover de ingenieur beschikt - tijd - wordt beperkt door het universum.
4. Het ergste en meest onaangename - als resultaat kan afval als "Geen muis, geen kikker, maar een onbekend klein dier" blijken.

Wie niet iets riskeert, drinkt geen champagne.
Dus, het plezier begint.

Algemeen idee - schematisch

Prestatiebewaking van PostgreSQL-query's. Deel 1 - rapportage
(Illustratie overgenomen uit artikel «Synthese als een van de methoden om de prestaties van PostgreSQL te verbeteren»)

toelichting:

  • De doeldatabase wordt geïnstalleerd met de standaard PostgreSQL-extensie "pg_stat_statements".
  • In de monitoringdatabase maken we een set servicetabellen om de geschiedenis van pg_stat_statements in de beginfase op te slaan en om metrieken en monitoring in de toekomst te configureren
  • Op de monitoringhost maken we een set bash-scripts, inclusief die voor het genereren van incidenten in het ticketsysteem.

Service tafels

Om te beginnen een schematisch vereenvoudigd ERD, wat er uiteindelijk gebeurde:
Prestatiebewaking van PostgreSQL-query's. Deel 1 - rapportage
Korte beschrijving van de tafelseindpunt - host, verbindingspunt naar de instantie
databank - database-opties
pg_stat_geschiedenis - historische tabel voor het opslaan van tijdelijke momentopnamen van de weergave pg_stat_statements van de doeldatabase
metrische_woordenlijst - Woordenboek van prestatiestatistieken
metrische_config - configuratie van individuele statistieken
metriek - een specifieke statistiek voor het verzoek dat wordt gecontroleerd
metrische_waarschuwingsgeschiedenis - geschiedenis van prestatiewaarschuwingen
log_query - servicetabel voor het opslaan van geparseerde records uit het PostgreSQL-logbestand dat is gedownload van AWS
basislijn - parameters van de tijdsperiode gebruikt als basis
checkpoint - configuratie van statistieken voor het controleren van de status van de database
checkpoint_alert_history - waarschuwingsgeschiedenis van statistieken voor databasestatuscontrole
pg_stat_db_queries — servicetabel met actieve verzoeken
activiteiten logboek - activiteitenlogboekservicetabel
trap_oid - val configuratie servicetabel

Fase 1 - verzamel prestatiestatistieken en ontvang rapporten

Een tabel wordt gebruikt om statistische informatie op te slaan. pg_stat_geschiedenis
pg_stat_history tabelstructuur

                                          Tabel "public.pg_stat_history" Kolom | typ | Wijzigingen --------------------+--------------------- --+---- -------------------------------- id | geheel getal | niet null standaard nextval('pg_stat_history_id_seq'::regclass) snapshot_timestamp | tijdstempel zonder tijdzone | database_id | geheel getal | dbid | oid | gebruikersnaam | oid | queryid | bigint | vraag | tekst | roept | bigint | totale_tijd | dubbele precisie | min_tijd | dubbele precisie | max_tijd | dubbele precisie | tussentijd | dubbele precisie | stddev_tijd | dubbele precisie | rijen | bigint | gedeelde_blks_hit | bigint | shared_blks_read | bigint | shared_blks_dirtied | bigint | shared_blks_written | bigint | lokale_blks_hit | bigint | local_blks_read | bigint | local_blks_dirtied | bigint | local_blks_written | bigint | temp_blks_read | bigint | temp_blks_geschreven | bigint | blk_read_time | dubbele precisie | blk_write_time | dubbele precisie | basislijn_id | geheel getal | Indexen: "pg_stat_history_pkey" PRIMAIRE SLEUTEL, btree (id) "database_idx" btree (database_id) "queryid_idx" btree (queryid) "snapshot_timestamp_idx" btree (snapshot_timestamp) Beperkingen externe sleutel: "database_id_fk" BUITENLANDSE SLEUTEL (database_id) REFERENTIES database(id ) AAN WISSEN CASCADE

Zoals u kunt zien, is de tabel slechts een cumulatieve weergave van gegevens pg_stat_statements in de doeldatabase.

Het gebruik van deze tabel is heel eenvoudig.

pg_stat_geschiedenis vertegenwoordigt de verzamelde statistieken van query-uitvoering voor elk uur. Aan het begin van elk uur, na het invullen van de tabel, statistieken pg_stat_statements resetten met pg_stat_statements_reset().
Opmerking: Statistieken worden verzameld voor verzoeken met een duur van meer dan 1 seconde.
De tabel pg_stat_history vullen

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

Als gevolg hiervan na een bepaalde tijd in de tabel pg_stat_geschiedenis we zullen een set snapshots hebben van de inhoud van de tabel pg_stat_statements doel database.

Eigenlijk aangifte doen

Met behulp van eenvoudige zoekopdrachten kunt u behoorlijk nuttige en interessante rapporten krijgen.

Geaggregeerde gegevens voor een bepaalde periode

onderzoek

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 ;

DB tijd

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

I/O-tijd

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

TOP10 SQL door total_time

onderzoek

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 PER TOTALE UITVOERTIJD | #| queryid| belt| belt %| totale_tijd (ms) | dbtijd % +----+-----------+-----------+-----------+------ ----------------------------------+--------- | 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 op basis van totale I/O-tijd

onderzoek

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 PER TOTALE I/O-TIJD | #| queryid| belt| belt %| I/O-tijd (ms)|db I/O-tijd % +----+----------+-----------+------ ---------------------------------------+----------- -- | 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 op maximale uitvoeringstijd

onderzoek

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 OP MAXIMALE UITVOERTIJD | #| momentopname| momentopnameID| queryid| max_tijd (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 door SHARED buffer lezen/schrijven

onderzoek

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 DOOR GEDEELDE BUFFER LEZEN/SCHRIJVEN | #| momentopname| momentopnameID| queryid| gedeelde blokken gelezen| gedeelde blokken schrijven +-----------------------------------+------------------------- --+---------------------+------ | 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 van querydistributie op basis van maximale uitvoeringstijd

verzoeken

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 | TOTAAL OPROEPEN: 33851920 | MIN TIJD: 00:00:01.063 | MAX TIJD: 00:02:01.869 ---------------------------------- -------- --------------------------- | minimale duur| maximale duur| oproepen +------------------------------------------------+--------------------------- -----------------------------------+---------- | 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 per zoekopdracht per seconde

verzoeken

--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 gerangschikt op QueryPerSeconds-nummers --------------------------------------- ------ ----------------------------- ------ ------------------------------------------ | #| momentopname| momentopnameID| belt| totale dbtijd| KPS | I/O-tijd | I/O-tijd % +-----+----------------------------------------------------- ----+--------------------+---------- --------------------------------------------------+----------- | 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

Uurlijkse uitvoeringsgeschiedenis met QueryPerSeconds en I/O-tijd

onderzoek

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 van alle SQL-selecties

onderzoek

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

Totaal

Zoals u kunt zien, kunt u met vrij eenvoudige middelen veel nuttige informatie verkrijgen over de werklast en de status van de database.

Opmerking:Als u de queryid in de query's corrigeert, krijgen we de geschiedenis voor een afzonderlijk verzoek (om ruimte te besparen, worden rapporten voor een afzonderlijk verzoek weggelaten).

Er zijn dus statistische gegevens over de queryprestaties beschikbaar en deze worden verzameld.
De eerste fase "verzameling van statistische gegevens" is voltooid.

U kunt doorgaan naar de tweede fase - "prestatiestatistieken configureren".
Prestatiebewaking van PostgreSQL-query's. Deel 1 - rapportage

Maar dit is een heel ander verhaal.

Wordt vervolgd ...

Bron: www.habr.com

Voeg een reactie