Die PostgreSQL Performance Schnelldiagnose
Hans-J¨urgen Sch¨onig
www.postgresql-support.de
Hans-J¨urgen Sch¨onig
www.postg...
Performance Probleme diagnostizieren
Hans-J¨urgen Sch¨onig
www.postgresql-support.de
Unser Ziel
Finden der h¨aufigsten Bottlenecks
L¨osen der wichtigsten Probleme
Viele Probleme k¨onnen mit wenigen Handgriffen...
Langsame Abfragen
Hans-J¨urgen Sch¨onig
www.postgresql-support.de
pg stat statements: Queries tracken
pg stat statements hilft, langsame Abfragen zu finden.
Eines der wichtigsten Module ¨ub...
pg stat statements aktivieren
postgresql.conf editieren:
“‘bash shared preload libraries = ‘pg stat statements’ -
PostgreS...
Wertvolle Information (1)
test=# d pg_stat_statements
View "public.pg_stat_statements"
Column | Type | Modifiers
---------...
Ausf¨uhrungszeiten
total time sagt uns, wieviel Zeit eine Art von Query in Summe
ben¨otigt hat.
Viele kurze Abfragen mache...
Wertvolle Information (2)
rows | bigint |
shared_blks_hit | bigint |
shared_blks_read | bigint |
shared_blks_dirtied | big...
Speichermanagement
*blkshit und *blksread k¨onnen zur Berechnung der Cache Hit
Rate verwendet werden.
Interessante Fragen:...
Wertvolle Information (3)
temp_blks_read | bigint |
temp_blks_written | bigint |
blk_read_time | double precision |
blk_wr...
I/O Timing
blk * time ist in den Default-Settings deaktiviert.
track io timing in postgresql.conf kann eingeschaltet werde...
pg test timing
Ergebnisse zwischen 19 und 1400 ns
iMac:~ hs$ pg_test_timing
Testing timing overhead for 3 seconds.
Per loo...
Relevanz erzeugen
pg stat statements sollte sortiert abgefragt werden.
Idealerweise immer im Context:
SELECT query, total_...
Indexing . . .
Hans-J¨urgen Sch¨onig
www.postgresql-support.de
Der ¨ubliche Bottleneck
Indices haben bei der Optimierung das gr¨oßte Potential
Indices sind oft der einfachste Weg, die P...
Was passieren kann
Man stelle sich vor:
Wir haben eine Tabelle mit 60.000 Eintr¨agen
Es fehlt ein einziger Index
Wir haben...
Wie findet man das?
Fehlenden Indices kann auf die Spur gekommen werden:
Durch das Auffinden langsamer Statements in
pg stat ...
Die wichtigste Query
Die wichtigste Query eures Lebens:
SELECT schemaname, relname, seq_scan, seq_tup_read,
idx_scan, seq_...
Interpretation der Daten
Wieso liest jemand 5 Millionen Zeilen 5 Millionen mal?
Im “Problemfall” sieht man in seq tup read...
Zu viele Indexes (1)
Auch zu viele Indexes sind ein Problem
pg stat user indexes hilft bei der Diagnose:
test=# d pg_stat_...
Zu viele Indexes (2)
Zu viele Indexes sind viel “subtiler” als fehlende Indexes
Bedenke: Schreibzugriffe m¨ussen auch die I...
Typische Probleme mit Abfragen
Hans-J¨urgen Sch¨onig
www.postgresql-support.de
LIKE: Der klassische Killer
LIKE Abfragen f¨uhren in vielen Anwendungen zu Sequential
Scans
Abfragen k¨onnen sehr leicht b...
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 r...
Semantische Fehler
Meistens ist es ein semantisches Problem, das als Performance
Problem daher kommt.
Bedenke: UNION filter...
I/O Performance
Hans-J¨urgen Sch¨onig
www.postgresql-support.de
Schreibperformance
Wer kennt diese Meldung?
checkpoints are occurring too frequently (%d second apart)
Hans-J¨urgen Sch¨on...
Checkpoints
Checkpoints sind teuer
Die Default Distanz zwischen zwei Checkpoints ist sehr sehr
niedrig
H¨ohere Checkpoint ...
Finally . . .
Hans-J¨urgen Sch¨onig
www.postgresql-support.de
Contact us . . .
Cybertec Sch¨onig & Sch¨onig GmbH
Gr¨ohrm¨uhlgasse 26
A-2700 Wiener Neustadt Austria
More than 15 years o...
Nächste SlideShare
Wird geladen in …5
×

5min analyse

307 Aufrufe

Veröffentlicht am

Performance Tuning muss in PostgreSQL nicht schwer sein. Oft reichen einige einfache Veränderung, um die Datenbank massiv zu beschleunigen.
VIele Performance Probleme sind einfach zu lösen. Diese Präsentation zeigt die gängigsten Methoden, um einfache Probleme schnell und effizient zu beseitigen

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
307
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
8
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

5min analyse

  1. 1. Die PostgreSQL Performance Schnelldiagnose Hans-J¨urgen Sch¨onig www.postgresql-support.de Hans-J¨urgen Sch¨onig www.postgresql-support.de
  2. 2. Performance Probleme diagnostizieren Hans-J¨urgen Sch¨onig www.postgresql-support.de
  3. 3. Unser Ziel Finden der h¨aufigsten Bottlenecks L¨osen der wichtigsten Probleme Viele Probleme k¨onnen mit wenigen Handgriffen gel¨ost werden. Diese Anleitung ist in keinster Weise vollst¨andig! Hans-J¨urgen Sch¨onig www.postgresql-support.de
  4. 4. Langsame Abfragen Hans-J¨urgen Sch¨onig www.postgresql-support.de
  5. 5. pg stat statements: Queries tracken pg stat statements hilft, langsame Abfragen zu finden. Eines der wichtigsten Module ¨uberhaupt Sollte in jeder Database aktiviert sein Hans-J¨urgen Sch¨onig www.postgresql-support.de
  6. 6. pg stat statements aktivieren postgresql.conf editieren: “‘bash shared preload libraries = ‘pg stat statements’ - PostgreSQL muss neu gestartet werden Die Extension installieren: CREATE EXTENSION pg_stat_statements; Hans-J¨urgen Sch¨onig www.postgresql-support.de
  7. 7. 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-J¨urgen Sch¨onig www.postgresql-support.de
  8. 8. Ausf¨uhrungszeiten total time sagt uns, wieviel Zeit eine Art von Query in Summe ben¨otigt hat. Viele kurze Abfragen machen oft viel mehr Aufwand als wenige große Queries. Die Standardabweichung (stddev time) sagt, wie gleichm¨aßig die Database antwortet. Eine hohe Standardabweichung kann viele Ursachen haben: Ungleiche Verteilung der Daten Probleme im Zusammenhang mit Locking Hans-J¨urgen Sch¨onig www.postgresql-support.de
  9. 9. 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-J¨urgen Sch¨onig www.postgresql-support.de
  10. 10. Speichermanagement *blkshit und *blksread k¨onnen zur Berechnung der Cache Hit Rate verwendet werden. Interessante Fragen: Ist die Anzahl der Bl¨ocke pro Query sinnvoll? Ist die Cache Hit Rate brauchbar? Werden viele lokale Buffer verwendet? Gibt eine Query unnat¨urlich viele Zeilen zur¨uck? Hans-J¨urgen Sch¨onig www.postgresql-support.de
  11. 11. Wertvolle Information (3) temp_blks_read | bigint | temp_blks_written | bigint | blk_read_time | double precision | blk_write_time | double precision | Hohe temp * Werte k¨onnen auf falsche work mem Settings oder fehlende Indices hinweisen Hans-J¨urgen Sch¨onig www.postgresql-support.de
  12. 12. I/O Timing blk * time ist in den Default-Settings deaktiviert. track io timing in postgresql.conf kann eingeschaltet werden. Das Messen der Zeit kann etwas Overhead erzeugen. Um diesen Overhead zu bestimmen, gibt es ein Tool names pg test timing. Hans-J¨urgen Sch¨onig www.postgresql-support.de
  13. 13. pg test timing 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-J¨urgen Sch¨onig www.postgresql-support.de
  14. 14. Relevanz erzeugen pg stat statements sollte sortiert abgefragt werden. Idealerweise immer im Context: SELECT query, total_time, calls, sum(total_time) OVER () FROM pg_stat_statements ORDER BY total_time DESC LIMIT 20; Ein Beispiel: http://www.cybertec.at/2015/10/pg stat statements-the- way-i-like-it/ Hans-J¨urgen Sch¨onig www.postgresql-support.de
  15. 15. Indexing . . . Hans-J¨urgen Sch¨onig www.postgresql-support.de
  16. 16. Der ¨ubliche Bottleneck Indices haben bei der Optimierung das gr¨oßte Potential Indices sind oft der einfachste Weg, die Performance zu verbessern Nichts wird so oft vergessen wie ein Index Nicht ist so “uncool” wie ein Index Leute optimieren lieber RAID Level, Filesystem Settings, Kernel Parameter, Speicher, etc. Hans-J¨urgen Sch¨onig www.postgresql-support.de
  17. 17. Was passieren kann Man stelle sich vor: Wir haben eine Tabelle mit 60.000 Eintr¨agen Es fehlt ein einziger Index Wir haben 1.000 Requests / Sekunde Das System liest 60.000.000 Zeilen vollkommen umsonst. Liest Du gerne das ganze Telefonbuch, um eine einzige Nummer zu finden? Hans-J¨urgen Sch¨onig www.postgresql-support.de
  18. 18. Wie findet man das? Fehlenden Indices kann auf die Spur gekommen werden: Durch das Auffinden langsamer Statements in pg stat statements Durch geschicktes Auswerten von pg stat user tables Oft sind die problematischen Spalten offensichtlich Hans-J¨urgen Sch¨onig www.postgresql-support.de
  19. 19. Die wichtigste Query 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-J¨urgen Sch¨onig www.postgresql-support.de
  20. 20. Interpretation der Daten Wieso liest jemand 5 Millionen Zeilen 5 Millionen mal? Im “Problemfall” sieht man in seq tup read so etwas wie einen “Hockeystick” Es wird immer Sequential Scans geben Viele teure Scans sind das Problem Die Daten sind alle da Oft werden die Daten ignoriert oder falsch interpretiert Hans-J¨urgen Sch¨onig www.postgresql-support.de
  21. 21. Zu viele Indexes (1) Auch zu viele Indexes sind ein Problem 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-J¨urgen Sch¨onig www.postgresql-support.de
  22. 22. Zu viele Indexes (2) Zu viele Indexes sind viel “subtiler” als fehlende Indexes Bedenke: Schreibzugriffe m¨ussen auch die Indexes updaten Indexes f¨uhren sehr oft zu Random I/O Random I/O ist teuer Hans-J¨urgen Sch¨onig www.postgresql-support.de
  23. 23. Typische Probleme mit Abfragen Hans-J¨urgen Sch¨onig www.postgresql-support.de
  24. 24. LIKE: Der klassische Killer LIKE Abfragen f¨uhren in vielen Anwendungen zu Sequential Scans Abfragen k¨onnen sehr leicht beschleunigt werden: CREATE EXTENSION pg_trgm; CREATE INDEX idx ON tab USING gist (spalte gist_trgm_ops); Hans-J¨urgen Sch¨onig www.postgresql-support.de
  25. 25. 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-J¨urgen Sch¨onig www.postgresql-support.de
  26. 26. Semantische Fehler Meistens ist es ein semantisches Problem, das als Performance Problem daher kommt. Bedenke: UNION filtert doppelte Eintr¨age. Beachte: Kann es ¨uberhaupt doppelte Eintr¨age geben? Hans-J¨urgen Sch¨onig www.postgresql-support.de
  27. 27. I/O Performance Hans-J¨urgen Sch¨onig www.postgresql-support.de
  28. 28. Schreibperformance Wer kennt diese Meldung? checkpoints are occurring too frequently (%d second apart) Hans-J¨urgen Sch¨onig www.postgresql-support.de
  29. 29. Checkpoints Checkpoints sind teuer Die Default Distanz zwischen zwei Checkpoints ist sehr sehr niedrig H¨ohere Checkpoint Distanzen beschleunigen Schreibzugriffe Hans-J¨urgen Sch¨onig www.postgresql-support.de
  30. 30. Finally . . . Hans-J¨urgen Sch¨onig www.postgresql-support.de
  31. 31. Contact us . . . Cybertec Sch¨onig & Sch¨onig GmbH Gr¨ohrm¨uhlgasse 26 A-2700 Wiener Neustadt Austria More than 15 years of PostgreSQL experience: Training Consulting 24x7 support Hans-J¨urgen Sch¨onig www.postgresql-support.de

×