Surveillance des performances des requêtes PostgreSQL. Partie 1 - rapports

Ingénieur - traduit du latin - inspiré.
Un ingénieur peut tout faire. (c) R. Diesel.
Épigraphes.

Ou une histoire sur la raison pour laquelle un administrateur de base de données doit se souvenir de son passé de programmation.

Avant-propos

Tous les noms ont été changés. Les matchs sont aléatoires. Le matériel est uniquement l'opinion personnelle de l'auteur.

Exclusion de garanties: dans la série d'articles prévue, il n'y aura pas de description détaillée et précise des tables et des scripts utilisés. Les matériaux ne peuvent pas être immédiatement utilisés "TELS QUELS".
Tout d'abord, en raison de la grande quantité de matériel,
deuxièmement, en raison de l'acuité avec la base de production d'un vrai client.
Par conséquent, seules les idées et les descriptions sous la forme la plus générale seront données dans les articles.
Peut-être qu'à l'avenir, le système atteindra le niveau de publication sur GitHub, ou peut-être pas. Le temps nous montrera.

Début de l'histoire-Te souviens-tu comment tout a commencé».
Que s'est-il passé en conséquence, dans les termes les plus généraux - "La synthèse comme l'une des méthodes pour améliorer les performances de PostgreSQL»

Pourquoi ai-je besoin de tout cela ?

Eh bien, d'abord, pour ne pas s'oublier, se souvenir des jours glorieux de la retraite.
Deuxièmement, systématiser ce qui a été écrit. Pour moi déjà, parfois je commence à être confus et à oublier des parties séparées.

Eh bien, et le plus important - tout à coup, cela peut être utile pour quelqu'un et aider à ne pas réinventer la roue et à ne pas collecter de râteau. En d'autres termes, améliorez votre karma (pas Khabrovsky). Car la chose la plus précieuse au monde, ce sont les idées. L'essentiel est de trouver une idée. Et traduire l'idée en réalité est déjà une question purement technique.

Alors commençons doucement...

Formulation du problème.

Il y a:

PostgreSQL(10.5), charge mixte (OLTP+DSS), charge moyenne à légère, hébergé dans le cloud AWS.
Il n'y a pas de surveillance de la base de données, la surveillance de l'infrastructure est présentée comme des outils AWS standard dans une configuration minimale.

nécessite:

Surveillez les performances et l'état de la base de données, recherchez et disposez des informations initiales pour optimiser les requêtes de base de données lourdes.

Brève introduction ou analyse des solutions

Pour commencer, essayons d'analyser les options pour résoudre le problème du point de vue d'une analyse comparative des avantages et des inconvénients pour l'ingénieur, et laissons ceux qui sont censés figurer sur la liste du personnel s'occuper des avantages et des pertes de la direction.

Option 1 - "Travailler à la demande"

Nous laissons tout tel quel. Si le client n'est pas satisfait de quelque chose dans la santé, les performances de la base de données ou de l'application, il en informera les ingénieurs DBA par e-mail ou en créant un incident dans la boîte à tickets.
Un ingénieur, ayant reçu une notification, comprendra le problème, proposera une solution ou mettra le problème de côté, en espérant que tout se résoudra de lui-même, et de toute façon, tout sera bientôt oublié.
Pain d'épice et beignets, contusions et bossesPain d'épice et beignets :
1. Rien de plus à faire
2. Il y a toujours la possibilité de sortir et de se salir.
3. Beaucoup de temps que vous pouvez consacrer à vous-même.
Ecchymoses et bosses :
1. Tôt ou tard, le client réfléchira à l'essence de l'être et de la justice universelle dans ce monde et se posera une fois de plus la question - pourquoi est-ce que je lui paie mon argent ? La conséquence est toujours la même - la seule question est de savoir quand le client s'ennuie et dit au revoir. Et la mangeoire est vide. C'est triste.
2. Le développement d'un ingénieur est nul.
3. Difficultés à planifier le travail et le chargement

Option 2 - "Danser avec des tambourins, mettre et mettre des chaussures"

Paragraphe 1-Pourquoi avons-nous besoin d'un système de surveillance, nous recevrons toutes les demandes. Nous lançons un tas de toutes sortes de requêtes dans le dictionnaire de données et les vues dynamiques, activons toutes sortes de compteurs, mettons tout dans des tableaux, analysons périodiquement des listes et des tableaux, pour ainsi dire. Du coup, on a de beaux ou pas très graphiques, tableaux, rapports. La principale chose - ce serait plus, plus.
Paragraphe 2-Générer l'activité-exécuter l'analyse de tout cela.
Paragraphe 3-Nous préparons un certain document, nous appelons ce document, simplement - "comment équipons-nous la base de données."
Paragraphe 4- Le client, voyant toute cette splendeur de graphiques et de chiffres, est dans une confidence naïve enfantine - maintenant tout fonctionnera pour nous, bientôt. Et se séparer facilement et sans douleur de leurs ressources financières. La direction est également convaincue que nos ingénieurs travaillent dur. Charge maximale.
Paragraphe 5- Répétez l'étape 1 régulièrement.
Pain d'épice et beignets, contusions et bossesPain d'épice et beignets :
1. La vie des managers et des ingénieurs est simple, prévisible et remplie d'activités. Tout bourdonne, tout le monde est occupé.
2. La vie du client n'est pas mauvaise non plus - il est toujours sûr que vous devez être un peu patient et que tout ira bien. Ça ne s'améliore pas, eh bien - ce monde est injuste, dans la prochaine vie - tu auras de la chance.
Ecchymoses et bosses :
1. Tôt ou tard, il y aura un fournisseur plus intelligent d'un service similaire qui fera la même chose, mais un peu moins cher. Et si le résultat est le même, pourquoi payer plus. Ce qui conduira à nouveau à la disparition de la mangeoire.
2. C'est ennuyeux. Comme c'est ennuyeux toute petite activité significative.
3. Comme dans la version précédente - pas de développement. Mais pour un ingénieur, le moins est que, contrairement à la première option, vous devez ici générer en permanence une IDB. Et cela prend du temps. Qui peut être dépensé au profit de votre bien-aimé. Car vous ne pouvez pas prendre soin de vous, tout le monde se soucie de vous.

Option 3-Pas besoin d'inventer un vélo, vous devez l'acheter et le monter.

Les ingénieurs d'autres entreprises mangent sciemment de la pizza avec de la bière (oh, les temps glorieux de Saint-Pétersbourg dans les années 90). Utilisons des systèmes de surveillance qui sont faits, débogués et qui fonctionnent, et d'une manière générale, ils apportent des avantages (enfin, du moins à leurs créateurs).
Pain d'épice et beignets, contusions et bossesPain d'épice et beignets :
1. Inutile de perdre du temps à inventer ce qui est déjà inventé. Prenez et utilisez.
2. Les systèmes de surveillance ne sont pas écrits par des imbéciles, et bien sûr ils sont utiles.
3. Les systèmes de surveillance fonctionnels fournissent généralement des informations filtrées utiles.
Ecchymoses et bosses :
1. Dans ce cas, l'ingénieur n'est pas un ingénieur, mais simplement un utilisateur du produit de quelqu'un d'autre.
2. Le client doit être convaincu de la nécessité d'acheter quelque chose qu'il ne veut généralement pas comprendre, et il ne devrait pas, et en général le budget de l'année a été approuvé et ne changera pas. Ensuite, vous devez allouer une ressource distincte, la configurer pour un système spécifique. Ceux. Vous devez d'abord payer, payer et payer à nouveau. Et le client est avare. C'est la norme de cette vie.

Que faire, Chernyshevsky ? Votre question est très pertinente. (Avec)

Dans ce cas particulier et la situation actuelle, vous pouvez faire un peu différemment - faisons notre propre système de surveillance.

Eh bien, pas un système, bien sûr, au sens plein du terme, c'est trop bruyant et présomptueux, mais au moins facilitez-vous la tâche et collectez plus d'informations pour résoudre les incidents de performance. Pour ne pas se retrouver dans une situation - "allez-y, je ne sais pas où, trouvez ça, je ne sais pas quoi."

Quels sont les avantages et inconvénients de cette option :

Avantages:
1. C'est intéressant. Eh bien, au moins plus intéressant que la constante "rétrécir le fichier de données, modifier l'espace de table, etc."
2. Ce sont de nouvelles compétences et de nouveaux développements. Ce qui à l'avenir donnera tôt ou tard du pain d'épice et des beignets bien mérités.
Inconvénients:
1. Avoir à travailler. Travaille beaucoup.
2. Vous devrez expliquer régulièrement le sens et les perspectives de toute activité.
3. Quelque chose devra être sacrifié, car la seule ressource disponible pour l'ingénieur - le temps - est limitée par l'Univers.
4. Le pire et le plus désagréable - en conséquence, des ordures comme "Pas une souris, pas une grenouille, mais un petit animal inconnu" peuvent se révéler.

Qui ne risque rien ne boit pas de champagne.
Ainsi, le plaisir commence.

Idée générale - schématique

(Illustration tirée de l'article «La synthèse comme l'une des méthodes pour améliorer les performances de PostgreSQL»)

Explication:

• La base de données cible est installée avec l'extension PostgreSQL standard "pg_stat_statements".
• Dans la base de données de surveillance, nous créons un ensemble de tables de service pour stocker l'historique de pg_stat_statements au stade initial et pour configurer les métriques et la surveillance à l'avenir
• Sur l'hôte de surveillance, nous créons un ensemble de scripts bash, y compris ceux pour générer des incidents dans le système de tickets.

Tables de service

Pour commencer, un ERD schématiquement simplifié, ce qui s'est passé au final :

Brève description des tableauxpoint final - hôte, point de connexion à l'instance
base de données - options de base de données
pg_stat_history - une table historique pour stocker des instantanés temporaires de la vue pg_stat_statements de la base de données cible
glossaire_métrique - Dictionnaire des métriques de performance
metric_config - configuration de métriques individuelles
métrique - une métrique spécifique pour la demande qui est surveillée
metric_alert_history - historique des avertissements de performance
log_query - table de service pour stocker les enregistrements analysés à partir du fichier journal PostgreSQL téléchargé depuis AWS
de base - paramètres de la période de temps utilisée comme base
point de contrôle - configuration de métriques pour vérifier l'état de la base de données
checkpoint_alert_history - historique des avertissements des métriques de vérification de l'état de la base de données
pg_stat_db_queries — tableau de service des demandes actives
journal d'activité — table de service de journal d'activité
trap_oid - tableau de service de configuration des pièges

Étape 1 - collecter des statistiques de performances et obtenir des rapports

Une table est utilisée pour stocker des informations statistiques. pg_stat_history
Structure de la table pg_stat_history

                                          Tableau "public.pg_stat_history" Colonne | taper | Modificateurs ---------------------+-----------------------+----------------------------------------------------------------- id | entier | not null par défaut nextval('pg_stat_history_id_seq'::regclass) snapshot_timestamp | horodatage sans fuseau horaire | id_base de données | entier | dbid | oïde | ID utilisateur | oïde | ID requête | gros_int | requête | texte | appels | gros_int | temps_total | double précision | temps_min | double précision | temps_max | double précision | temps_moyen | double précision | heure_dev_std | double précision | lignes | gros_int | partagé_blks_hit | gros_int | lecture_blks_partagée | gros_int | partagé_blks_dirtied | gros_int | partagé_blks_écrit | gros_int | local_blks_hit | gros_int | local_blks_read | gros_int | local_blks_dirtied | gros_int | local_blks_écrit | gros_int | temp_blks_read | gros_int | temp_blks_écrit | gros_int | blk_read_time | double précision | blk_write_time | double précision | id_baseline | entier | Index : "pg_stat_history_pkey" clé primaire, Btree (id) "Database_idx" BTREE (DATABASE_ID) "Queryid_idx" BTREE (QUERYID) "SNAPSHOT_TIMESTAMP_IDX" BTREE (SNAPSHOTRE (SNAPSH _timestamp)

Comme vous pouvez le voir, le tableau n'est qu'une vue cumulative des données pg_stat_statements dans la base de données cible.

L'utilisation de ce tableau est très simple.

pg_stat_history représentera les statistiques cumulées d'exécution de la requête pour chaque heure. Au début de chaque heure, après avoir rempli le tableau, des statistiques pg_stat_statements réinitialiser avec pg_stat_statements_reset().
Note: Les statistiques sont collectées pour les requêtes d'une durée supérieure à 1 seconde.
Remplir la table 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;

En conséquence, après un certain temps dans le tableau pg_stat_history nous aurons un ensemble d'instantanés du contenu de la table pg_stat_statements base de données cible.

Rapportant réellement

En utilisant des requêtes simples, vous pouvez obtenir des rapports très utiles et intéressants.

Données agrégées pour une période de temps donnée

Demande

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 ;

Heure DB

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

Temps d'E/S

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

TOP10 SQL par total_time

Demande

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 PAR TEMPS D'EXÉCUTION TOTAL | #| id_requête| appels| appels %| temps_total (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 par temps d'E/S total

Demande

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 PAR TEMPS E/S TOTAL | #| id_requête| appels | appels %| Temps d'E/S (ms)|db Temps d'E/S % +----+-----------+-----------+-----------+---------------------------+-------------- | 1| 4152624390| 2| .00001|00:08:31.616( 511616.592 ms.)| 31.06 juin | 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.35h4 | 2460318461| 1| 00000| .00|04:05.981:245981.117( 14.93 ms.)| 5 | 1484454471| 4| 00001| .00|00:39.144:39144.221( 2.38 ms.)| 6 | 2194493487| 4| 00001| .00|00:18.182:18182.816( 1.10 ms.)| 7 | 1053044345| 1| 00000| .00|00:16.611:16611.722( 1.01 ms.)| 8 | 3644780286| 1| 00000| .00|00:00.436:436.205( 03 ms.)| .XNUMX

TOP10 SQL par temps d'exécution maximum

Demande

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 PAR TEMPS D'EXÉCUTION MAX | #| instantané| ID d'instantané| id_requête| temps_max (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 par tampon SHARED lecture/écriture

Demande

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 PAR TAMPON PARTAGÉ LECTURE/ÉCRITURE | #| instantané| ID d'instantané| id_requête| blocs partagés lus | blocs partagés écrivent +----+------------+-----------+-----------+---------------------+--------------------- | 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 -------------------------------------------------------------------------------------------

Histogramme de distribution des requêtes par temps d'exécution maximal

demandes

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 HISTOGRAMME | TOTAL APPELS : 33851920 | TEMPS MINI : 00:00:01.063 | TEMPS MAX : 00:02:01.869 --------------------------------------------------------------------------------- | durée min | durée max | appels +---------------------------------+----------------------------------+---------- | 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 des instantanés par requête par seconde

demandes

--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 des instantanés classés par nombre de QueryPerSeconds ---------------------------------------------------------------------------------------------------------------------------------------------------------- | #| instantané| ID d'instantané| appels | temps db total | RPS | Temps d'E/S | Temps d'E/S % +-----+------------------+-----------+-----------+----------------------------------+-----------+----------------------------------+----------- | 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

Historique d'exécution horaire avec QueryPerSeconds et I/O Time

Demande

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

Texte de toutes les sélections SQL

Demande

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

Comme vous pouvez le voir, par des moyens assez simples, vous pouvez obtenir de nombreuses informations utiles sur la charge de travail et l'état de la base de données.

Note:Si vous corrigez le queryid dans les requêtes, nous obtiendrons l'historique d'une requête distincte (afin d'économiser de l'espace, les rapports pour une requête distincte sont omis).

Ainsi, des données statistiques sur les performances des requêtes sont disponibles et collectées.
La première étape "collecte des données statistiques" est terminée.

Vous pouvez passer à la deuxième étape - "Configuration des métriques de performance".


Mais c'est une histoire complètement différente.

A suivre ...

Source: habr.com