Download - 5min analyse
![Page 1: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/1.jpg)
Die PostgreSQL Performance Schnelldiagnose
Hans-Jurgen Schonig
www.postgresql-support.de
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 2: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/2.jpg)
Performance Probleme diagnostizieren
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 3: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/3.jpg)
Unser Ziel
I Finden der haufigsten Bottlenecks
I Losen der wichtigsten Probleme
I Viele Probleme konnen mit wenigen Handgriffen gelostwerden.
I Diese Anleitung ist in keinster Weise vollstandig!
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 4: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/4.jpg)
Langsame Abfragen
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 5: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/5.jpg)
pg stat statements: Queries tracken
I pg stat statements hilft, langsame Abfragen zu finden.
I Eines der wichtigsten Module uberhaupt
I Sollte in jeder Database aktiviert sein
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 6: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/6.jpg)
pg stat statements aktivieren
I postgresql.conf editieren:
“‘bash shared preload libraries = ‘pg stat statements’ -PostgreSQL muss neu gestartet werden
I Die Extension installieren:
CREATE EXTENSION pg_stat_statements;
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 7: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/7.jpg)
Wertvolle Information (1)
test=# \d pg_stat_statements
View "public.pg_stat_statements"
Column | Type | Modifiers
---------------------+------------------+-----------
...
query | text |
calls | bigint |
total_time | double precision |
min_time | double precision |
max_time | double precision |
mean_time | double precision |
stddev_time | double precision |
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 8: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/8.jpg)
Ausfuhrungszeiten
I total time sagt uns, wieviel Zeit eine Art von Query in Summebenotigt hat.
I Viele kurze Abfragen machen oft viel mehr Aufwand alswenige große Queries.
I Die Standardabweichung (stddev time) sagt, wie gleichmaßigdie Database antwortet.
I Eine hohe Standardabweichung kann viele Ursachen haben:
I Ungleiche Verteilung der DatenI Probleme im Zusammenhang mit Locking
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 9: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/9.jpg)
Wertvolle Information (2)
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 |
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 10: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/10.jpg)
Speichermanagement
I *blkshit und *blksread konnen zur Berechnung der Cache HitRate verwendet werden.
I Interessante Fragen:
I Ist die Anzahl der Blocke pro Query sinnvoll?I Ist die Cache Hit Rate brauchbar?I Werden viele lokale Buffer verwendet?I Gibt eine Query unnaturlich viele Zeilen zuruck?
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 11: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/11.jpg)
Wertvolle Information (3)
temp_blks_read | bigint |
temp_blks_written | bigint |
blk_read_time | double precision |
blk_write_time | double precision |
I Hohe temp * Werte konnen auf falsche work mem Settingsoder fehlende Indices hinweisen
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 12: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/12.jpg)
I/O Timing
I blk * time ist in den Default-Settings deaktiviert.I track io timing in postgresql.conf kann eingeschaltet werden.I Das Messen der Zeit kann etwas Overhead erzeugen.I Um diesen Overhead zu bestimmen, gibt es ein Tool names
pg test timing.
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 13: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/13.jpg)
pg test timing
I Ergebnisse zwischen 19 und 1400 ns
iMac:~ hs$ pg_test_timing
Testing timing overhead for 3 seconds.
Per loop time including overhead: 39.18 nsec
Histogram of timing durations:
< usec % of total count
1 96.14291 73610005
2 3.85010 2947759
4 0.00032 248
8 0.00012 92
16 0.00636 4866
32 0.00016 123
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 14: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/14.jpg)
Relevanz erzeugen
I pg stat statements sollte sortiert abgefragt werden.I Idealerweise immer im Context:
SELECT query, total_time, calls, sum(total_time) OVER ()
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 20;
I Ein Beispiel:http://www.cybertec.at/2015/10/pg stat statements-the-way-i-like-it/
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 15: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/15.jpg)
Indexing . . .
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 16: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/16.jpg)
Der ubliche Bottleneck
I Indices haben bei der Optimierung das großte Potential
I Indices sind oft der einfachste Weg, die Performance zuverbessern
I Nichts wird so oft vergessen wie ein Index
I Nicht ist so “uncool” wie ein Index
I Leute optimieren lieber RAID Level, Filesystem Settings,Kernel Parameter, Speicher, etc.
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 17: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/17.jpg)
Was passieren kann
I Man stelle sich vor:
I Wir haben eine Tabelle mit 60.000 EintragenI Es fehlt ein einziger IndexI Wir haben 1.000 Requests / Sekunde
I Das System liest 60.000.000 Zeilen vollkommen umsonst.
I Liest Du gerne das ganze Telefonbuch, um eine einzigeNummer zu finden?
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 18: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/18.jpg)
Wie findet man das?
I Fehlenden Indices kann auf die Spur gekommen werden:
I Durch das Auffinden langsamer Statements inpg stat statements
I Durch geschicktes Auswerten von pg stat user tables
I Oft sind die problematischen Spalten offensichtlich
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 19: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/19.jpg)
Die wichtigste Query
I Die wichtigste Query eures Lebens:
SELECT schemaname, relname, seq_scan, seq_tup_read,
idx_scan, seq_tup_read / seq_scan AS avg
FROM pg_stat_user_tables
WHERE seq_scan > 0
ORDER BY seq_tup_read DESC
LIMIT 25;
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 20: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/20.jpg)
Interpretation der Daten
I Wieso liest jemand 5 Millionen Zeilen 5 Millionen mal?
I Im “Problemfall” sieht man in seq tup read so etwas wieeinen “Hockeystick”
I Es wird immer Sequential Scans geben
I Viele teure Scans sind das Problem
I Die Daten sind alle da
I Oft werden die Daten ignoriert oder falsch interpretiert
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 21: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/21.jpg)
Zu viele Indexes (1)
I Auch zu viele Indexes sind ein ProblemI pg stat user indexes hilft bei der Diagnose:
test=# \d pg_stat_user_indexes
View "pg_catalog.pg_stat_user_indexes"
Column | Type | Modifiers
---------------+--------+-----------
schemaname | name |
relname | name |
indexrelname | name |
idx_scan | bigint |
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 22: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/22.jpg)
Zu viele Indexes (2)
I Zu viele Indexes sind viel “subtiler” als fehlende IndexesI Bedenke: Schreibzugriffe mussen auch die Indexes updatenI Indexes fuhren sehr oft zu Random I/OI Random I/O ist teuer
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 23: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/23.jpg)
Typische Probleme mit Abfragen
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 24: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/24.jpg)
LIKE: Der klassische Killer
I LIKE Abfragen fuhren in vielen Anwendungen zu SequentialScans
I Abfragen konnen sehr leicht beschleunigt werden:
CREATE EXTENSION pg_trgm;
CREATE INDEX idx ON tab USING gist (spalte gist_trgm_ops);
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 25: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/25.jpg)
UNION vs. UNION ALL
SELECT 1 AS n UNION ALL SELECT 1;
n
---
1
1
(2 rows)
test=# SELECT 1 AS n UNION SELECT 1;
n
---
1
(1 row)
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 26: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/26.jpg)
Semantische Fehler
I Meistens ist es ein semantisches Problem, das als PerformanceProblem daher kommt.
I Bedenke: UNION filtert doppelte Eintrage.
I Beachte: Kann es uberhaupt doppelte Eintrage geben?
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 27: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/27.jpg)
I/O Performance
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 28: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/28.jpg)
Schreibperformance
I Wer kennt diese Meldung?
checkpoints are occurring too frequently (%d second apart)
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 29: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/29.jpg)
Checkpoints
I Checkpoints sind teuerI Die Default Distanz zwischen zwei Checkpoints ist sehr sehr
niedrigI Hohere Checkpoint Distanzen beschleunigen Schreibzugriffe
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 30: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/30.jpg)
Finally . . .
Hans-Jurgen Schonigwww.postgresql-support.de
![Page 31: 5min analyse](https://reader033.vdocuments.pub/reader033/viewer/2022042600/587f3cde1a28ab43318b4e71/html5/thumbnails/31.jpg)
Contact us . . .
Cybertec Schonig & Schonig GmbH
Grohrmuhlgasse 26
A-2700 Wiener Neustadt Austria
I More than 15 years of PostgreSQL experience:
I TrainingI ConsultingI 24x7 support
Hans-Jurgen Schonigwww.postgresql-support.de