PostgreSQL er en svært tilpasses relasjonsdatabase management system (RDBMS) med en imponerende rekke konfigurasjonsmuligheter. Heldigvis, særlig i de senere versjoner av PostgreSQL, de fleste av disse innstillingene trenger ikke å bli forandret. Trikset er å finne ut hvilke alternativer gjør
må endres og hvilke verdier som er mest hensiktsmessig.

Noen få minutter brukt justere postgresql.conf filen kan føre til store ytelsesforbedringer. Ytterligere forbedringer kan være mulig med tilstrekkelig tid og tanke, men i denne artikkelen vil jeg fokusere på hvordan du raskt få innstillingene til høyre omtrentlig.

En av de viktigste metoder for å forbedre PostgreSQL ytelse, spesielt på store datasett, er å øke parameter shared_buffers, som kontrollerer mengden minne PostgreSQL bruker for sin egen buffer cache. Fordi PostgreSQL også gjør bruk av systemet buffer cache, og av andre grunner, erfaring har vist at det er vanligvis best å sette denne parameteren til ca 25% av systemminnet på UNIX og Linux-systemer, men ikke mer enn ca 8 GB. (Noen ganger 8GB er allerede for mye.)

I Windows, enda mindre verdiene er hensiktsmessig, mellom 256 og 512. Raising denne parameteren kan forårsake PostgreSQL ikke å starte, fordi de fleste operativsystem distribusjoner har svært konservative begrensninger på hvor mye av System V delt minne som kan tildeles som standard. Heldigvis gir dokumentasjon PostgreSQL detaljerte instruksjoner om hvordan du kan øke disse grensene, og prosessen er vanligvis ikke vanskelig.

Bortsett fra shared_buffers, er den viktigste parameteren minne tildeling work_mem. Standardverdien på 1MB gjør noe slag, hash bli med, eller materialisere operasjon for å bruke opp til 1 MB fysisk minne. Større operasjoner vil bruke en mindre effektiv algoritme som gjør at data søle til disk. Heve denne verdien kan dramatisk forbedre ytelsen til visse spørsmål, men det er viktig å ikke overdrive det. I verste fall kan hver forbindelse være å utføre flere typer samtidig, så hvis du har 100 samtidige tilkoblinger til databasen og work_mem er satt til 10 MB, kan du bruke flere gigabyte med minne – hvis du ikke har nok, vil systemet begynne å bytte, og ytelsen vil slippe av dramatisk. Rimelige verdier er vanligvis mellom 4 MB og 64 MB, avhengig av størrelsen på din maskin, hvor mange samtidige tilkoblinger du forventer, og kompleksiteten av dine spørsmål.

Mens du setter work_mem, er det også en god idé å sette relaterte parameter maintenance_work_mem, som kontrollerer mengden fysisk minne PostgreSQL vil forsøke å bruke for vedlikeholdsoperasjoner, som for eksempel rutine støvsuging og indeksopprettelse. Som med work_mem, er det viktig ikke å sette denne parameteren så høy at systemet begynner å bytte, men fordi det er sjelden å ha mer enn 3 eller 4 vedlikeholdsoperasjoner som pågår samtidig, er det ikke nødvendig å være ganske så forsiktig om verdien. En god tommelfingerregel er å sette denne til omtrent 5% av systemminne, men ikke mer enn omtrent 512. Større verdier vil ikke nødvendigvis forbedre ytelsen.

Til slutt, bør du øke standardverdien wal_buffers, som standard til 64 kB. Men selv dette svært liten innstilling ikke alltid føre til et problem, er det situasjoner der det kan resultere i ekstra fsync samtaler, og fornedre generelle systemgjennomgangen. Øke denne verdien til 1MB eller så kan avhjelpe dette problemet. På meget travle systemer, kan en enda høyere verdi være nødvendig, opp til et maksimum på omtrent 16 MB. Som shared_buffers øker dette parameter PostgreSQL innledende delt minne tildeling, så hvis bumping det opp fører til at systemet ikke vil starte, må du øke operativsystemet grensen.

Tuning Checkpoint Parametere

Når du har fått minnerelaterte parametre satt riktig, den neste tingen du bør tenke på å gjøre er tuning dine sjekkpunkt parametere. Øke checkpoint_segments parameter, som standard til 3, dramatisk kan forbedre ytelsen under bulk data belastninger. En rimelig startverdien er 30. Når du har økt denne parameteren, er det også fornuftig å øke checkpoint_completion_target, som standard til 0,5, til 0,9; dette vil redusere ytelsen virkningen av checkpointing på en travel system (men er ineffektiv for små verdier av checkpoint_segments, som er grunnen til standard er 0,5).

Til slutt, økende checkpoint_timeout fra 5 minutter til en større verdi, for eksempel som 15 minutter, kan redusere I /O belastningen på systemet ditt, spesielt når du bruker store verdier for shared_buffers. Ulempen med å gjøre disse justeringene er at systemet vil bruke en beskjeden mengde ekstra diskplass, og vil ta lengre tid å komme i tilfelle en krasj. Men for de fleste brukere, dette er en liten pris å betale for en betydelig ytelsesforbedring.

Med minnetildeling og sjekkpunkt parametere ut av veien, er det på tide å justere planner parametere. Disse innstillingene er vanligvis ikke fullt så viktig som minnetildeling og sjekkpunkt parametere, men de kan definitivt gjøre en forskjell, spesielt på mer komplekse spørringer. Parametrene random_page_cost og seq_page_cost, styrer planleggeren anslag over hvor dyrt det vil være å få hver database side. Standardverdiene anta svært lite caching, så det er ofte en god idé å redusere dem. Selv om databasen er vesentlig større enn fysisk minne, kan det være lurt å forsøke å sette disse parametrene til 2 og 1 (i stedet for standardverdiene på 4 og 1) for å se om du får bedre spørring planer på den måten. Hvis databasen passer helt innenfor minne, kan du redusere disse verdiene mye mer, kanskje til 0,1 og 0,1. Aldri satt random_page_cost mindre enn seq_page_cost, men vurdere å sette dem lik (eller svært nær lik) hvis databasen passer det meste eller helt innenfor minne.

Du bør også konfigurere para effective_cache_size. Selv om det blir målt i megabyte, ikke denne parameteren ikke fordele noe minne. I stedet er det brukt av spørringen planlegger å estimere visse caching effekter. Når denne parameteren er satt for lavt, kan planleggeren bestemme seg for ikke å bruke en indeks selv når det ville være gunstig å gjøre det. En passende verdi er ca 75% av det fysiske minnet.

Til slutt, for best mulig ytelse, er det en god idé å vurdere å sette den synchronous_commit parameter til off. Når denne parameteren er slått av, kan en uventet krasjer eller strømbrudd føre til tap av en transaksjon som ble rapportert til klienten som begått. For økonomiske eller andre forretningskritiske applikasjoner, er dette uakseptabelt, og standardverdien på bør beholdes. Imidlertid kan mange webapplikasjoner tåle tap av noen få sekunder med oppdateringer i tilfelle en krasj, og ytelsen gevinst i å endre denne innstillingen kan være massiv.

Går Lenger

Hvis du bygger en database server fra bunnen av, er det mange ting du kan gjøre for å forbedre ytelsen og påliteligheten utover justere parametere i postgresql.conf. Greg Smith bok PostgreSQL 9.0 High Performance er den definitive guide til å bygge en høy ytelse PostgreSQL system, og kapitlet om database hardware (PDF) er fritt tilgjengelig som en prøve.

Den dekker ikke bare hvordan å maksimere ytelsen , men også trinnene du bør ta for å maksimere påliteligheten av databasen på enten nye eller eksisterende maskinvare. Hvis du er seriøs om å maksimere PostgreSQL ytelse, er både at kapittelet og resten av boken sterkt anbefalt lesning. Hvis derimot, du er en uformell PostgreSQL bruker eller bare prøver produktet ut, forslagene ovenfor vil gjøre deg får du mye av ytelsen nytte i en brøkdel av tiden.