Først skal du altid bruge den nyeste version af PostgreSQL. Ydeevneforbedringer kommer altid, så du spilder sandsynligvis din tid, hvis du tuner en gammel version. For eksempel forbedrer PostgreSQL 9.2 markant hastigheden af TRUNCATE og tilføjer selvfølgelig kun indeksscanninger. Selv mindre udgivelser bør altid følges; se versionspolitikken.
Lad være med
Gør IKKE læg et tablespace på en RAM-disk eller andet ikke-holdbart lager.
Hvis du mister et tablespace, kan hele databasen blive beskadiget og svær at bruge uden væsentligt arbejde. Der er meget lidt fordel ved dette sammenlignet med blot at bruge UNLOGGED tabeller og alligevel have masser af RAM til cache.
Hvis du virkelig ønsker et ramdisk-baseret system, initdb en helt ny klynge på ramdisken af initdb ing af en ny PostgreSQL-instans på ramdisken, så du har en fuldstændig engangs-PostgreSQL-instans.
PostgreSQL-serverkonfiguration
Når du tester, kan du konfigurere din server til ikke-holdbar, men hurtigere drift.
Dette er en af de eneste acceptable anvendelser af fsync=off indstilling i PostgreSQL. Denne indstilling fortæller stort set, at PostgreSQL ikke skal genere ordnede skrivninger eller andre grimme dataintegritetsbeskyttelse og nedbrudssikkerhedsting, hvilket giver den tilladelse til fuldstændig at smide dine data, hvis du mister strømmen eller har et OS-nedbrud.
Det er overflødigt at sige, at du aldrig bør aktivere fsync=off i produktion, medmindre du bruger Pg som en midlertidig database for data, du kan gengenerere fra andre steder. Hvis og kun hvis du gør for at slå fsync fra, kan du også slå full_page_writes af, da det ikke længere nytter. Pas på at fsync=off og full_page_writes ansøg på klyngen niveau, så de påvirker alle databaser i din PostgreSQL-instans.
Til produktionsbrug kan du eventuelt bruge synchronous_commit=off og indstil en commit_delay , da du får mange af de samme fordele som fsync=off uden den gigantiske risiko for datakorruption. Du har et lille vindue til tab af seneste data, hvis du aktiverer async commit - men det er det.
Hvis du har mulighed for at ændre DDL lidt, kan du også bruge UNLOGGED tabeller i Pg 9.1+ for helt at undgå WAL-logning og få et reelt hastighedsboost på bekostning af, at tabellerne bliver slettet, hvis serveren går ned. Der er ingen konfigurationsmulighed til at gøre alle tabeller uloggede, den skal indstilles under CREATE TABLE . Ud over at være god til at teste er dette praktisk, hvis du har tabeller fulde af genererede eller uvigtige data i en database, der ellers indeholder ting, du har brug for for at være sikker.
Tjek dine logfiler og se, om du får advarsler om for mange kontrolpunkter. Hvis du er, bør du øge dine checkpoint_segments. Du vil måske også justere dit checkpoint_completion_target for at glatte udskrivninger.
Indstil shared_buffers for at passe til din arbejdsbyrde. Dette er OS-afhængigt, afhænger af, hvad der ellers sker med din maskine, og kræver nogle forsøg og fejl. Standardindstillingerne er ekstremt konservative. Du skal muligvis øge operativsystemets maksimale delte hukommelsesgrænse, hvis du øger shared_buffers på PostgreSQL 9.2 og derunder; 9.3 og nyere ændrede, hvordan de bruger delt hukommelse for at undgå det.
Hvis du kun bruger et par forbindelser, der gør en masse arbejde, skal du øge work_mem for at give dem mere RAM at lege med for sortering osv. Pas på, at en for høj work_mem indstilling kan forårsage problemer med manglende hukommelse, fordi den er per-sort ikke per-forbindelse, så en forespørgsel kan have mange indlejrede sorteringer. Du kun virkelig skal øge work_mem hvis du kan se sorter, der spildes til disken i EXPLAIN eller logget med log_temp_files indstilling (anbefales), men en højere værdi kan også lade Pg vælge smartere planer.
Som sagt af en anden plakat her, er det klogt at lægge xlog og hovedtabellerne/indekserne på separate HDD'er, hvis det er muligt. Separate partitioner er ret meningsløst, du vil virkelig have separate drev. Denne adskillelse har meget mindre fordel, hvis du kører med fsync=off og næsten ingen, hvis du bruger UNLOGGED tabeller.
Til sidst skal du justere dine forespørgsler. Sørg for, at din random_page_cost og seq_page_cost afspejle dit systems ydeevne, sørg for din effective_cache_size er korrekt osv. Brug EXPLAIN (BUFFERS, ANALYZE) for at undersøge individuelle forespørgselsplaner, og drej auto_explain modul på for at rapportere alle langsomme forespørgsler. Du kan ofte forbedre forespørgselsydeevnen dramatisk blot ved at oprette et passende indeks eller justere omkostningsparametrene.
AFAIK der er ingen måde at indstille en hel database eller klynge som UNLOGGED . Det ville være interessant at kunne gøre det. Overvej at spørge på PostgreSQL-mailinglisten.
Værts OS tuning
Der er også nogle justeringer, du kan foretage på operativsystemniveau. Det vigtigste, du måske vil gøre, er at overbevise operativsystemet om ikke at skylle skrivninger til disk aggressivt, da du virkelig er ligeglad med, hvornår/om de kommer til disken.
I Linux kan du styre dette med det virtuelle hukommelsesundersystems dirty_* indstillinger, såsom dirty_writeback_centisecs .
Det eneste problem med at indstille tilbageskrivningsindstillingerne til at være for slappe er, at en flush fra et andet program kan forårsage, at alle PostgreSQL's akkumulerede buffere også bliver skyllet, hvilket forårsager store stall, mens alt blokerer for skrivning. Du kan muligvis afhjælpe dette ved at køre PostgreSQL på et andet filsystem, men nogle flush kan være på enhedsniveau eller hele værtsniveau ikke filsystemniveau, så det kan du ikke stole på.
Denne indstilling kræver virkelig at lege med indstillingerne for at se, hvad der fungerer bedst for din arbejdsbyrde.
På nyere kerner ønsker du måske at sikre, at vm.zone_reclaim_mode er sat til nul, da det kan forårsage alvorlige ydeevneproblemer med NUMA-systemer (de fleste systemer i dag) på grund af interaktioner med, hvordan PostgreSQL administrerer shared_buffers .
Justering af forespørgsler og arbejdsbelastning
Dette er ting, der kræver kodeændringer; de passer måske ikke til dig. Nogle er ting, du måske kan anvende.
Hvis du ikke samler arbejde i større transaktioner, så start. Masser af små transaktioner er dyre, så du bør batch ting, når det er muligt og praktisk at gøre det. Hvis du bruger async commit, er dette mindre vigtigt, men det anbefales stadig stærkt.
Når det er muligt, brug midlertidige tabeller. De genererer ikke WAL-trafik, så de er meget hurtigere til indsættelser og opdateringer. Nogle gange er det værd at slurpe en masse data ind i en midlertidig tabel, manipulere den, som du har brug for det, og derefter lave en INSERT INTO ... SELECT ... for at kopiere det til finalebordet. Bemærk, at midlertidige tabeller er per-session; hvis din session slutter, eller du mister din forbindelse, forsvinder temp-tabellen, og ingen anden forbindelse kan se indholdet af en sessions midlertidige tabeller.
Hvis du bruger PostgreSQL 9.1 eller nyere, kan du bruge UNLOGGED tabeller for data, du har råd til at miste, såsom sessionstilstand. Disse er synlige på tværs af forskellige sessioner og bevares mellem forbindelser. De bliver afkortet, hvis serveren lukker urene ned, så de ikke kan bruges til noget, du ikke kan genskabe, men de er gode til caches, materialiserede visninger, tilstandstabeller osv.
Generelt må du ikke DELETE FROM blah; . Brug TRUNCATE TABLE blah; i stedet; det er meget hurtigere, når du dumper alle rækker i en tabel. Afkort mange tabeller i én TRUNCATE ring hvis du kan. Der er en advarsel, hvis du laver mange TRUNCATES af små borde igen og igen, dog; se:Postgresql trunkeringshastighed
Hvis du ikke har indekser på fremmednøgler, DELETE s, der involverer de primære nøgler, der refereres til af disse fremmednøgler, vil være forfærdeligt langsomme. Sørg for at oprette sådanne indekser, hvis du nogensinde forventer at DELETE fra den eller de refererede tabeller. Indeks er ikke påkrævet for TRUNCATE .
Opret ikke indekser, du ikke har brug for. Hvert indeks har en vedligeholdelsesomkostning. Prøv at bruge et minimalt sæt indekser og lad bitmap-indeksscanninger kombinere dem i stedet for at opretholde for mange enorme, dyre indekser med flere kolonner. Hvor der kræves indekser, prøv først at udfylde tabellen, og opret derefter indekser til sidst.
Hardware
At have nok RAM til at holde hele databasen er en kæmpe gevinst, hvis du kan administrere den.
Hvis du ikke har nok RAM, jo hurtigere lagring du kan få, jo bedre. Selv en billig SSD gør en enorm forskel i forhold til spinding rust. Stol dog ikke på billige SSD'er til produktion, de er ofte ikke nedbrudssikre og kan spise dine data.
Læring
Greg Smiths bog, PostgreSQL 9.0 High Performance forbliver relevant på trods af at der henvises til en noget ældre version. Det burde være en nyttig reference.
Tilmeld dig PostgreSQL's generelle postliste og følg den.
Læser:
- Justering af din PostgreSQL-server - PostgreSQL-wiki
- Antal databaseforbindelser - PostgreSQL wiki