sql >> Database teknologi >  >> RDS >> PostgreSQL

PostgreSQL Tuning:Nøgle ting til at drive ydeevne

PostgreSQL og ydeevne

Ydeevne er et af nøglekravene i design af softwarearkitektur og har været i fokus for PostgreSQL-udviklere siden starten, også vist i følgende PostgreSQL Git-kilder:

commit d31084e9d1118b25fd16580d9d8c2924b5740dff
Author: Marc G. Fournier <[email protected]>
Date:   Tue Jul 9 06:22:35 1996 +0000

   Postgres95 1.01 Distribution - Virgin Sources

[...]

diff --git a/src/backend/access/heap/stats.c b/src/backend/access/heap/stats.c
new file mode 100644
index 0000000000..d41d01ac1b
--- /dev/null
+++ b/src/backend/access/heap/stats.c
@@ -0,0 +1,329 @@
+/*-------------------------------------------------------------------------
+ *
+ * stats.c--
+ *    heap access method debugging statistic collection routines
+ *
+ * Copyright (c) 1994, Regents of the University of California

[...]

+ * Also note that this routine probably shouldn't have to exist, and does
+ * screw up the call graph rather badly, but we are wasting so much time and
+ * system resources being massively general that we are losing badly in our
+ * performance benchmarks.
+ */

PostgreSQL opnår ydeevne ved at implementere forskellige funktioner:

  • Flere indekstyper
  • Forespørgselsplanlægger og -optimering, der kan drage fordel af multiprocessorsystemer
  • MVCC
  • Tabelopdeling

Valg af miljø

Med de mange muligheder, der er tilgængelige i dag, kommer så mange spørgsmål:

  • På stedet eller i skyen?
  • Bent metal eller virtualiseret?
  • Hardware mærket eller bygge din egen?
  • Hvordan påvirker PostgreSQL lavniveaufunktionerne eller fsync hardwareydelsen?
  • Lokal disk eller delt lager?
  • Hvilke styresystemer skal indstilles?

Igen, PostgreSQL-wikien er et meget godt udgangspunkt for alt, hvad der angår ydeevne.

Hvad er de vigtigste ting at se efter?

Da der er masser af litteratur derude, der berører forskellige aspekter af PostgreSQL-ydeevnejustering og systemdesign (tip:søg på siden efter xfs), er denne blog ikke beregnet til at være et dybt dyk ned i nogen af ​​de allerede diskuterede emner, men snarere en sysadmins perspektiv på, hvor man skal starte, når hovedfokus er at undgå ressourcestridigheder. Jeg vil også pege på mange referencer, der behandler specifikke problemstillinger mere detaljeret. Ekspertrådgivning på alle områder, der er kritiske for PostgreSQL-ydelse, er tilgængelig gennem de mange virksomheder, der tilbyder professionelle tjenester.

Lad os starte!

Informationsindsamling

Hvis vi antager en standardinstallation og ved, at PostgreSQL ikke forsøger at være godt tunet ud af boksen, og der kan endda være nogle særheder, involverer dette trin opsætning af de nødvendige overvågningsværktøjer.

God overvågning er afgørende for at forstå applikationer og hurtigt kunne spore de berørte ressourcer, og dette gælder især for cloud-udbydere, hvor adgang til databaseværten muligvis ikke er tilgængelig for at køre benchmarks for CPU eller I/O:

Fig.1 — SlideShare, Jignesh Shah, Best Practices with Managed PostgreSQL in the Cloud

Reagerer på alarmer om systemets ydeevne

Overvågningsværktøjer viser grafer og advarer om systemets ydeevneindikatorer:

CPU:

  • Advarsel — Højt forbrug indikerer en langvarig forespørgsel.
    • Påvirkning — Appens responstid.
    • Handling — Gennemgå metrics for databasestatistik for at identificere forespørgsler, der skal justeres.

I/O:

  • Alarm — Højt tal eller læsninger.
    • Påvirkning — Appens responstid.
    • Handling — Tilføj endnu en læst replika. Gennemgå databasestatistik-metrics for at identificere langvarige forespørgsler.
  • Alarm — Højt antal skrivninger.
    • Påvirkning — Appens responstid.
    • Handling — Juster GUC-parametre shared_buffers, work_mem og maintenance_work_mem. Indstil checkpointeren, og sørg for, at autovakuum er indstillet korrekt. Hvis PostgreSQL er installeret på egen hardware, konfigurer tablespaces og/eller overvej sharding, men forstå sharding forbeholdene.

Hukommelse:

  • Advarsel — Højt hukommelsesforbrug.
    • Påvirkning — I/O-ydeevne.
    • Handling — Gennemgå metrics for databasestatistik for at identificere forespørgsler, der skal justeres.

Netværk:

  • Alarm — høj forsinkelse. Normalt er dette et DBaaS-problem.
    • Påvirkning — Klienter, replikering.
    • Handling — Flyt databaseværter tættere på frontend-servere.
  • Alarm — Højt antal forbindelser.
    • Påvirkning — Klienter.
    • Handling — Overvej at bruge forbindelsesafstemning.

Indikatorer for databasens interne ydeevne

Pg_*-visningerne er vinduet til databasemotorens ydeevne, og PostgreSQL-administrationsapplikationer er blevet skrevet for at hjælpe med at korrelere den mængde information, der ellers er tilgængelig via forskellige SQL-forespørgsler. Der findes yderligere udvidelser, og de er ofte integrerede eller tilgængelige som plugins.

Brug af sådanne værktøjer forenkler DBA-opgaven og sikrer, at bedste praksis følges ved opsætning og konfiguration af databaseklyngen.

Databasestatistik

Overvågningsværktøjer såsom ClusterControl bruger databaseaktivitetsstatistikker til at hjælpe DBA med ydelsesjustering:

Fig.2 — Severalnines, centrale ting at overvåge i PostgreSQL — Analyse af din arbejdsmængdeDownload Whitepaper Today med ClusterControlLær om, hvad du skal vide for at implementere, overvåge, administrere og skalere PostgreSQLDownload hvidbogen

Forespørgselsjustering

Fra og med version 9.5 indeholder PostgreSQL betydelige forbedringer af forespørgselsydeevnen såsom BRIN-indekser og parallelle forespørgsler:

Fig.3 — 2nd Quadrant, Thomas Vondra, Performance Improvements in PostgreSQL 9.5 (and beyond)

Låsning

Concurrency Control er dedikeret et helt kapitel i PostgreSQL-dokumentation. Brug overvågningsværktøjer til at blive advaret, når antallet af låse eller låsevarigheden overstiger tærsklen, og løs problemet ved at lede efter manglende indekser, gennemgå applikationskoden eller ved at skifte til forbindelsespolling.

Massebelastning

synchronous_commit kan slås fra under store dataimporter. Flere muligheder er diskuteret i PostgreSQL-dokumentationsafsnittet Udfyldning af en database.

Konklusion

PostgreSQL-indstilling af ydeevne er en kompleks opgave. Kompleksiteten kommer fra de mange tunables, der stilles til rådighed, hvilket er et stærkt argument til fordel for PostgreSQL. Der er ingen sølvkugle til at løse præstationsproblemer, snarere er det applikationsspecifikationerne, der i sidste ende dikterer tuning-kravene. Derfor kan overvågningsværktøjer hjælpe med at få indsigt i ydeevnen i forhold til systemets ydeevne og yderligere gøre det muligt at identificere de PostgreSQL-specifikke områder, der skal justeres, såvel som de SQL-forespørgsler, der kræver optimering. Derudover kan databasestyringssystemer hjælpe med opsætning og administration af PostgreSQL for at sikre, at bedste praksis følges.


  1. Lær, hvordan du udfører en procedure i Toad For Oracle

  2. Read Committed er et must for Postgres-kompatible distribuerede SQL-databaser

  3. Enum i Hibernate, fortsætter som en enum

  4. Tilladt hukommelsesstørrelse på 8589934592 bytes opbrugt