Ingeniør – oversatt fra latin – inspirert.
En ingeniør kan gjøre alt. (c) R. Diesel.
Epigrafer.
Eller en historie om hvorfor en databaseadministrator bør huske fortiden sin som programmerer.
Forord
Alle navn er endret. Tilfeldigheter er tilfeldige. Materialet representerer utelukkende forfatterens personlige mening.
Ansvarsfraskrivelse for garantier: Den planlagte artikkelserien vil ikke inneholde en detaljert og presis beskrivelse av tabellene og skriptene som er brukt. Materialene vil ikke umiddelbart kunne brukes «SOM DE ER».
For det første, på grunn av den store mengden materiale,
for det andre, på grunn av fokuset på produksjonsbasen til en reell kunde.
Derfor vil artiklene kun inneholde ideer og beskrivelser i den mest generelle formen.
Kanskje systemet i fremtiden vil vokse til nivået med publisering på GitHub, eller kanskje ikke. Tiden vil vise.
Begynnelsen av historien - "'.
Hva som skjedde som et resultat, i de mest generelle termene - "»
Hvorfor trenger jeg alt dette?
Vel, først av alt, slik at jeg ikke glemmer det, minnes jeg de strålende dagene i pensjonisttilværelsen.
For det andre, å systematisere det som står skrevet. Fordi noen ganger begynner jeg selv å bli forvirret og glemmer enkeltdeler.
Vel, og det viktigste – kanskje det vil være nyttig for noen og hjelpe deg med å ikke oppfinne hjulet på nytt og ikke samle raker. Med andre ord, å forbedre karmaen din (ikke Habr). Fordi det mest verdifulle i denne verden er ideer. Det viktigste er å finne en idé. Og å realisere ideen til virkelighet er allerede et rent teknisk spørsmål.
Så la oss begynne, litt etter litt...
Problemformulering.
Tilgjengelig:
PostgreSQL-database (10.5), blandet arbeidsmengde (OLTP+DSS), middels til lav belastning, plassert i AWS-skyen.
Det er ingen databaseovervåking; infrastrukturovervåking leveres i form av standard AWS-verktøy i en minimal konfigurasjon.
krever:
Overvåk databaseytelse og -tilstand, finn og ha innledende informasjon for å optimalisere tunge databasespørringer.
Kort introduksjon eller analyse av løsningsalternativer
Til å begynne med, la oss prøve å analysere alternativene for å løse problemet fra synspunktet om en sammenlignende analyse av fordeler og ulemper for ingeniøren, og la de som skal håndtere fordelene og tapene ved ledelsen i henhold til bemanningsplanen håndtere dem.
Alternativ 1 – «Arbeid på forespørsel»
Vi lar alt være som det er. Hvis kunden ikke er fornøyd med noe i funksjonaliteten, ytelsen til databasen eller applikasjonen, vil han varsle DBA-ingeniørene via e-post eller ved å opprette en hendelse i saken.
Ingeniøren, etter å ha mottatt varselet, vil løse problemet, tilby en løsning eller legge problemet på hylla, i håp om at alt løser seg av seg selv, og uansett vil alt snart være glemt.
Pepperkaker og smultringer, blåmerker og kulerPepperkaker og smultringer:
1. Det er ikke nødvendig å gjøre noe ekstra
2. Det er alltid en mulighet til å komme med unnskyldninger og unnskylde seg.
3. Massevis av tid til å bruke som du ønsker.
Blåmerker og støt:
1. Før eller siden vil kunden tenke på essensen av eksistens og universell rettferdighet i denne verden og nok en gang stille seg selv spørsmålet – hva betaler jeg dem pengene mine for? Konsekvensen er alltid den samme – spørsmålet er først når kunden blir lei og vinker farvel. Og trauet vil være tomt. Dette er trist.
2. Ingeniørutvikling er null.
3. Vanskeligheter med å planlegge arbeid og lasting
Alternativ 2 – «Vi danser med tamburiner, selger og skoer»
Punkt 1– Hvorfor trenger vi et overvåkingssystem? Vi mottar alt gjennom forespørsler. Jeg sender en rekke forespørsler til dataordboken og dynamiske visninger, slår på alle slags tellere, reduserer alt til tabeller, analyserer lister og tabeller med jevne mellomrom. Som et resultat har vi vakre eller ikke fullt så vakre grafer, tabeller, rapporter. Hovedsaken er at det blir mer, mer.
Punkt 2– Vi genererer aktivitet – vi setter i gang en analyse av alt dette.
Punkt 3– Vi utarbeider et bestemt dokument, vi kaller dette dokumentet ganske enkelt – «hvordan sette opp en database».
Punkt 4– Kunden, som ser all denne prakten av grafer og figurer, er i barnslig naiv tillit – nå vil alt fungere for oss, snart. Og enkelt og smertefritt skiller han seg av med sine økonomiske ressurser. Ledelsen er også trygg – ingeniørene våre jobber wow. Arbeidsmengden er på sitt maksimale.
Punkt 5-Gjenta punkt 1 regelmessig.
Pepperkaker og smultringer, blåmerker og kulerPepperkaker og smultringer:
1. Lederes og ingeniørers liv er enkelt, forutsigbart og fylt med aktivitet. Alt summer, alle er opptatt.
2. Kundens liv er heller ikke verst – han er alltid sikker på at han må være tålmodig en liten stund, så ordner alt seg. Hvis det ikke ordner seg, vel, verden er urettferdig, han vil være heldig i neste liv.
Blåmerker og støt:
1. Før eller siden vil det komme en raskere 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 bunnen forsvinner.
2. Det er kjedelig. Like kjedelig som enhver aktivitet som har liten mening.
3. Som i det forrige alternativet – ingen utvikling. Men for en ingeniør er ulempen at du, i motsetning til det første alternativet, her må generere IBD hele tiden. Og dette tar tid. Som kan brukes til din egen fordel. For hvis du ikke tar vare på deg selv, er det ingen som bryr seg om deg.
Alternativ 3 – Du trenger ikke å oppfinne en sykkel, du trenger bare å kjøpe den og sykle på den.
Ingeniører fra andre selskaper spiser pizza og drikker øl av en grunn (å, 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 fordeler (vel, i hvert fall for skaperne sine).
Pepperkaker og smultringer, blåmerker og kulerPepperkaker og smultringer:
1. Du trenger ikke å kaste bort tid på å finne opp noe som allerede er oppfunnet. Ta det og bruk det.
2. Overvåkingssystemer er ikke skrevet av dårer, og de er absolutt 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 noen andres produkt. Eller en bruker.
2. Kunden må overbevises om behovet for å kjøpe noe som han generelt ikke vil forstå, og ikke burde forstå, og generelt sett er budsjettet for året godkjent og vil ikke endres. Deretter må du tildele en egen ressurs, konfigurere den for et spesifikt system. Det vil si at du først må betale, betale og betale igjen. Og kunden er gjerrig. Dette er normen i dette livet.
Hva skal man gjøre – Tsjernysjevskij? Spørsmålet ditt er veldig passende. (c)
I dette tilfellet og den nåværende situasjonen kan du handle litt annerledes - La oss lage vårt eget overvåkingssystem.
Vel, ikke et system, selvfølgelig, i ordets fulle forstand, det er for høyt sagt og arrogant, men i det minste på en eller annen måte gjøre oppgaven enklere og samle inn mer informasjon for å løse ytelseshendelser. Slik at du ikke havner 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 hvert fall mer interessant enn den konstante "krymp datafil, endre tabellplass osv."
2. Dette er nye ferdigheter og ny utvikling. Som på lang sikt før eller siden vil gi de fortjente pepperkakene og smultringene.
Cons:
1. Du må jobbe. Jobb mye.
2. Du må regelmessig forklare betydningen av og utsiktene til alle aktiviteter.
3. Noe må ofres, fordi den eneste ressursen som er tilgjengelig for en ingeniør – tid – er begrenset av universet.
4. Det mest forferdelige og det mest ubehagelige – som et resultat kan du få noe sånt som «Ikke en mus, ikke en frosk, men et ukjent dyr».
Den som ikke tar risikoer, drikker ikke champagne.
Så begynner den mest interessante delen.
Generell idé - skjematisk
(Illustrasjon hentet fra artikkelen «")
Forklaring:
- Standard PostgreSQL-utvidelsen «pg_stat_statements» er installert i måldatabasen.
- I overvåkingsdatabasen oppretter vi et sett med tjenestetabeller for å lagre pg_stat_statements-historikken i den innledende fasen og for å konfigurere målinger og overvåking i fremtiden.
- På overvåkingsverten oppretter vi et sett med bash-skript, inkludert for å generere hendelser i billettsystemet.
Serveringsbord
Til å begynne med, en skjematisk forenklet ERD, hva vi fikk til slutt:
Kort beskrivelse av tabellerendepunkt — vert, tilkoblingspunkt til instansen
database — databaseparametere
pg_stat_history — en historisk tabell for lagring av midlertidige øyeblikksbilder av pg_stat_statements-visningen av måldatabasen
metrisk_ordliste — ordbok for ytelsesmålinger
metrisk_konfigurasjon — konfigurasjon av individuelle målinger
metrisk — en spesifikk beregning for spørringen som overvåkes
metrisk_varslingshistorikk — historikk over ytelsesadvarsler
log_query — en verktøytabell for lagring av analyserte poster fra en PostgreSQL-loggfil lastet ned fra AWS
baseline — parametere for tidsperioden som brukes som grunnlag
sjekkpunkt — konfigurasjon av databasens helsesjekkmålinger
checkpoint_alert_history — historikk over advarsler om databasehelsesjekkmålinger
pg_stat_db_queries — servicetabell over aktive forespørsler
aktivitetslogg — servicetabellen i aktivitetsloggen
trap_oid — tabell for fellekonfigurasjonstjenester
Trinn 1 – Samle inn ytelsesstatistikk og generer rapporter
En tabell brukes til å lagre statistisk informasjon. pg_stat_history
Strukturen til pg_stat_history-tabellen
Tabell "public.pg_stat_history" Kolonne | Type | Modifikatorer -------------------------+------------------------------+------------------------------------------ id | heltall | ikke null default nextval('pg_stat_history_id_seq'::regclass) snapshot_timestamp | tidsstempel uten tidssone | database_id | heltall | dbid | oid | brukerid | oid | spørreid | bigint | spørring | tekst | kall | bigint | total_tid | dobbel presisjon | min_tid | dobbel presisjon | maks_tid | dobbel presisjon | gjennomsnittstid | 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_write_time | 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 (snapshot_timestamp) Fremmednøkkelbegrensninger: "database_id_fk" FREMMEDNØKKEL (database_id) REFERANSER database(id) VED SLETING CASCADESom du kan se, er tabellen bare en kumulativ visning av dataene. pg_stat_statements i måldatabasen.
Det er veldig enkelt å bruke denne tabellen.
pg_stat_history vil representere den akkumulerte statistikken for spørringsutførelse for hver time. Ved begynnelsen av hver time, etter at tabellen er fylt ut, vil statistikken pg_stat_statements tilbakestill med pg_stat_statements_reset().
Merk: Statistikk samles inn for spørringer som tar mer enn ett sekund å utføre.
Fylling av 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 tid i tabellen pg_stat_history vi vil ha et sett med øyeblikksbilder av tabellinnholdet pg_stat_statements måldatabasen.
Den faktiske rapporteringen
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 ;DB-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')
TOPP 10 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------------------------------------------------------------------------- | TOPP 10 SQL ETTER TOTAL KJØRINGSTID | #| spørreid| kall| kall %| 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
TOPP 10 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------------------------------------------------------------------------ | TOPP 10 SQL ETTER TOTAL I/O-TID | #| spørringsid| kall| kall %| I/O-tid (ms)|db I/O-tid % +----+-----------+-----------+--------------------------+------------- | 1| 4152624390| 2| .00001|00:08:31.616( 511616.592 ms.)| 31.06 | 2| 821760255| 2| .00001|00:08:27.099( 507099.036 ms.)| 30.78 | 3| 655729273| 1| .00000|00:05:02.209(302209.137 ms.)| 18.35 | 4| 2460318461| 1| .00000|00:04:05.981(245981.117 ms.)| 14.93 | 5| 1484454471| 4| .00001|00:00:39.144(39144.221 ms.)| 2.38 | 6| 2194493487| 4| .00001|00:00:18.182(18182.816 ms.)| 1.10 | 7| 1053044345| 1| .00000|00:00:16.611(16611.722 ms.)| 1.01 | 8| 3644780286| 1| .00000|00:00:00.436(436.205 ms.)| .03
TOPP 10 SQL etter maks utførelsestid
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--------------------------------------------------------------------------- | TOPP 10 SQL ETTER MAKS. UTFØRINGSTID | #| snapshot| snapshotID| spørre-id| 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: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.)
TOPP 10 SQL ved lesing/skriving av SHARED-buffer
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----------------------------------------------------------------------------- | TOPP 10 SQL VIA DELT BUFFER LESING/SKRIVING | #| snapshot| snapshotID| spørringsid| delte blokker lest| delte blokker skrevet +----+------------------+------------+---------------------+-------------------------- | 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 ----------------------------------------------------------------------------------------------------------
Histogram over fordeling av spørringer 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 ) ;
|- ... | MAKS. TID HISTOGRAM | TOTALT ANTALL SAMTALER: 33851920 | MIN. TID: 00:00:01.063 | MAKS. TID: 00:02:01.869 ------------------------------------------------------------------------------------- | min. varighet| maks. varighet| samtaler +------------------------------------------+------------------------------------------------------------------------ | 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
TOPP 10 ø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
|----------------------------------------------------------------------------------------- | TOPP 10 øyeblikksbilder sortert etter tall for spørring per sekund ---------------------------------------------------------------------------------------------------------------------------------- | #| snapshot| snapshotID| kall| total db-tid| QPS| I/O-tid| I/O-tid % +-----+----+------------+------------+----------------------+------------------------------------- | 1| 04.04.2019/20/04 4161:5758631| 00| 06| 30.513:390513.926:1573.396( 00 ms.)| 00| 01.470:1470.110:376( 2 ms.)| .04.04.2019 | 17| 00/4149/3529197 00:11| 48.830| 708830.618| 980.332:00:12(47.834 ms.)| 767834.052| 108.324:3:04.04.2019(16 ms.)| 00 | 4143| 3525360/00/10 13.492:613492.351| 979.267| 00| 08:41.396:521396.555(84.988 ms.)| 4| 04.04.2019:21:03(4163 ms.)| 2781536 | 00| 03 06.470:186470.979| 785.745| 00| 00:00.249:249.865(134 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 ms.)| 8| 04.04.2019:13:00 (4135 ms.)| 2373043 | 00| 04 26.791:266791.988| 659.179| 00| 00:00.064:64.261 (024 ms.)| 9| 05.04.2019:01:03(4167 ms.)| 4387191 | 00| 06/51.380/411380.293 609.332:00| 05| 18.847| 318847.407:77.507:10(04.04.2019 ms.)| 18| 01:4157:1145596(00 ms.)| 01 | 19.217| 79217.372/313.004/00 00:01.319| 1319.676| 1.666| 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 for 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.
Note:Hvis du registrerer spørre-ID i forespørsler, vil du få historikk for en separat forespørsel (for å spare plass utelates rapporter for en separat forespørsel).
Så statistiske data om spørringsytelse er tilgjengelige og samlet inn.
Den første fasen, «innsamling av statistiske data», er fullført.
Du kan gå videre til andre trinn – «oppsette ytelsesmålinger».
Men det er en annen historie.
To be continued ...
Kilde: www.habr.com
