Konfigurera en optimal miljö för PostgreSQL

Välkommen till PostgreSQL, ett kraftfullt databassystem med öppen källkod som kan vara värd för allt från några megabyte kunddata för en småstadsföretag, till hundratals terabyte "big data" för multinationella företag. Oavsett applikation kommer det troligen att behövas en del installations- och konfigurationshjälp för att göra databasen redo för åtgärd.

När en ny server är installerad är PostgreSQL:s inställningar mycket minimala eftersom de är designade för att köras på minsta möjliga mängd hårdvara. Men de är mycket sällan optimala. Här kommer vi att gå igenom en grundläggande inställning för nya projekt, och hur man ställer in PostgreSQL för att köras mest optimalt på nya projekt.

Värd

Hosning på plats

Med en lokal databas är det bästa alternativet för en barmetallvärd, eftersom virtuella maskiner i allmänhet presterar långsammare såvida vi inte pratar om avancerade virtuella datorer på företagsnivå. Detta möjliggör också strängare kontroll över CPU-, minnes- och diskinställningar. Detta kommer dock med behovet av att ha en expert till hands (eller kontrakt) för att utföra serverunderhåll.

moln

Att vara värd för en databas i molnet kan vara underbart i vissa aspekter, eller en mardröm i andra. Såvida inte den valda molnplattformen är mycket optimerad (vilket i allmänhet innebär högre pris), kan den ha problem med miljöer med högre belastning. Håll utkik efter huruvida molnservern är delad eller dedikerad (dedikerad som tillåter full prestanda från servern för applikationen), samt nivån på IOPS (Input/output Operations Per Second) som tillhandahålls av en molnserver. När (eller om) applikationen växer till den grad att majoriteten av data inte kan lagras i minnet är diskåtkomsthastigheten avgörande.

Allmän värdinställning

De viktigaste pelarna som behövs för att på ett tillförlitligt sätt ställa in PostgreSQL är baserade på värdens CPU-, minnes- och diskförmågor. Beroende på applikationens behov kommer en tillräcklig värd och en välinställd PostgreSQL-konfiguration att ha en fantastisk inverkan på databassystemets prestanda.

Välja ett operativsystem

PostgreSQL kan kompileras på de flesta Unix-liknande operativsystem, såväl som Windows. Men prestanda på Windows är inte ens jämförbar med ett Unix-liknande system, så om det inte är för ett litet bortkastningsprojekt, kommer att hålla sig till ett etablerat Unix-liknande system vara vägen att gå. För den här diskussionen kommer vi att hålla oss till Linux-baserade system.

Den till synes mest använda Linux-distributionen som används för att vara värd för PostgreSQL är ett Red Hat-baserat system, som CentOS eller Scientific Linux, eller till och med Red Hat själv. Eftersom Red Hat och CentOS fokuserar på stabilitet och prestanda, arbetar gemenskapen bakom dessa projekt hårt för att se till att viktiga applikationer, såsom databaser, finns på den säkraste och mest pålitliga versionen av Linux som möjligt.

OBS:Linux har en rad kärnversioner som inte är optimala för att köra PostgreSQL, så de rekommenderas starkt att undvikas om möjligt (särskilt på applikationer där toppprestanda är av yttersta vikt). Benchmarks har visat att antalet transaktioner per sekund sjunker från kärnversion 3.4 – 3.10, men återställs och förbättras avsevärt i kärnan 3.12. Detta utesluter tyvärr att använda CentOS 7 om man går CentOS-vägen. CentOS 6 är fortfarande en giltig och stödd version av operativsystemet, och CentOS 8 förväntas släppas innan 6 inte längre stöds.

Installation

Installation kan göras antingen genom källa eller med hjälp av arkiv som underhålls av antingen distributionen av Linux vald, eller ännu bättre, PostgreSQL Global Development Group (PGDG), som underhåller arkiv för Red Hat-baserade system (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux och Fedora), samt paket för Debian och Ubuntu. Genom att använda PGDG-paketen säkerställs att uppdateringar av PostgreSQL är tillgängliga för uppdatering vid release, snarare än att vänta på att Linux-distributionens inbyggda förråd ska godkänna och tillhandahålla dem.

CPU

Nuförtiden är det inte svårt att ha flera kärnor tillgängliga för en databasvärd. PostgreSQL själv har först nyligen börjat lägga till flertrådsfunktioner på frågenivå, och kommer att bli mycket bättre under de kommande åren. Men även utan dessa nya och kommande förbättringar skapar PostgreSQL själv nya trådar för varje anslutning till databasen av en klient. Dessa trådar kommer i huvudsak att använda en kärna när de är aktiva, så antalet kärnor som krävs beror på nivån av nödvändiga samtidiga anslutningar och samtidiga frågor.

En bra baslinje att börja med är ett 4-kärnsystem för en liten applikation. Förutsatt att applikationer gör en dans mellan att köra frågor och vila, kan ett 4-kärnsystem hantera ett par dussin anslutningar innan det överbelastas. Att lägga till fler kärnor hjälper till att skala med en ökande arbetsbelastning. Det är inte ovanligt att mycket stora PostgreSQL-databaser har 48+ kärnor för att betjäna många hundra anslutningar.

Inställningstips: Även om hypertrådning är tillgängligt är transaktioner per sekund i allmänhet högre när hypertrådning är inaktiverat. För databasfrågor som inte är alltför komplexa, men högre i frekvens, är fler kärnor viktigare än snabbare kärnor.

Minne

Minne är en extremt viktig aspekt för PostgreSQL:s övergripande prestanda. Huvudinställningen för PostgreSQL när det gäller minne är shared_buffers, som är en del av minnet som allokeras direkt till PostgreSQL-servern för datacache. Ju högre sannolikhet det är att den data som behövs finns i minnet, desto snabbare återkommer frågorna och snabbare frågor innebär en effektivare processorkärninstallation som diskuterades i föregående avsnitt.

Förfrågningar behöver också ibland minne för att utföra sorteringsoperationer på data innan den returneras till klienten. Detta använder antingen extra ad-hoc-minne (separat från shared_buffers), eller temporära filer på disken, vilket är mycket långsammare.

Inställningstips: En grundläggande utgångspunkt för att ställa in shared_buffers är att ställa in den till 1/4 av värdet på tillgänglig systemminne. Detta gör att operativsystemet också kan göra sin egen cachning av data, såväl som alla andra processer som körs än själva databasen.

Att öka work_mem kan påskynda sorteringsoperationerna, men att öka den för mycket kan tvinga värden att ta slut på minne, eftersom värdeuppsättningen helt eller delvis kan utfärdas flera gånger per fråga. Om flera frågor begär flera minnesblock för sortering kan det snabbt lägga till mer minne än vad som är tillgängligt på värden. Håll den låg och höj den långsamt tills prestanda är där du vill.

Använd kommandot 'free' (som 'free -h'), ställ in effektiv_cache_size till summan av minne som är ledigt och cachelagrat. Detta låter frågeplaneraren veta vilken nivå av OS-cache kan vara tillgänglig och köra bättre frågeplaner.

Disk

Diskprestanda kan vara en av de viktigare sakerna att tänka på när du konfigurerar ett system. Inmatnings-/utgångshastigheter är viktiga för stora databelastningar eller för att hämta enorma mängder data som ska bearbetas. Det avgör också hur snabbt PostgreSQL kan synkronisera minne med disk för att hålla minnespoolen optimal.

Vissa förberedelser i diskar kan hjälpa till att omedelbart förbättra potentiell prestanda, samt framtidssäkra databassystemet för tillväxt.

• Separata diskar

  En ny installation av PostgreSQL kommer att skapa klustrets datakatalog någonstans på den huvudsakliga (och möjligen enda) tillgängliga enheten på systemet.

  En grundläggande installation med fler enheter skulle vara att lägga till en separat enhet (eller uppsättning enheter via RAID). Den har fördelen av att all databasrelaterad dataöverföring fungerar på en annan I/O-kanal än huvudoperativsystemet. Det låter också databasen växa utan rädsla för att otillräckligt utrymme orsakar problem och fel på andra ställen i operativsystemet.

  För databaser med extrem aktivitet kan katalogen PostgreSQL Transaction Log (xlog) placeras på ytterligare en enhet, och separera mer tung I/O till en annan kanal bort från huvudoperativsystemet såväl som huvuddatakatalogen. Detta är en avancerad åtgärd som hjälper till att pressa ut mer prestanda ur ett system, som annars kan vara nära dess gränser.

• Använder RAID

  Att ställa in RAID för databasenheterna skyddar inte bara från dataförlust, det kan också förbättra prestandan om du använder rätt RAID-konfiguration. RAID 1 eller 10 anses generellt vara bäst, och 10 erbjuder paritet och total hastighet. RAID 5 har dock högre redundansnivåer, men lider av betydande prestandaminskning på grund av hur den sprider data runt flera diskar. Planera ut det bästa tillgängliga alternativet med gott om utrymme för datatillväxt, och detta kommer att vara en konfiguration som inte behöver ändras ofta, om alls.

• Använder SSD

  Solid State Drives är underbara för prestanda, och om de når budgeten kan SSD:er för företag göra tung databearbetningsbelastning natt och dag snabbare. Mindre till medelstora databaser med mindre till medelstora arbetsbelastningar kan vara överdrivet, men när man kämpar för den minsta procentuella ökningen på stora applikationer, kan SSD vara den bästa kulan.

Inställningstips: Välj en enhetskonfiguration som är bäst för den aktuella applikationen och har gott om utrymme att växa med tiden när data ökar.

Om du använder en SSD kommer det att vara fördelaktigt för frågeplaneraren att ställa in random_page_cost till 1,5 eller 2 (standard är 4), eftersom slumpmässig datahämtning är mycket snabbare än på snurrande diskar.

Initiala konfigurationsinställningar

När du ställer in PostgreSQL för första gången finns det en handfull konfigurationsinställningar som enkelt kan ändras baserat på värdens kraft. Eftersom applikationen frågar databasen över tid, kan specifik justering göras baserat på applikationens behov. Men det kommer att bli ämnet för en separat trimblogg.

Minnesinställningar

shared_buffers:Ställ in på 1/4 av systemminnet. Om systemet har mindre än 1 GB totalt minne, ställ in på ~ 1/8 av det totala systemminnet

work_mem:Standard är 4MB, och kan till och med räcka för applikationen i fråga. Men om temporära filer skapas ofta, och dessa filer är ganska små (tiotals megabyte), kan det vara värt att höja den här inställningen. En konservativ ingångsnivå kan vara (1/4:e systemminne / max_anslutningar). Den här inställningen beror mycket på det faktiska beteendet och frekvensen av frågor till databasen, så bör endast ökas med försiktighet. Var redo att sänka den tillbaka till tidigare nivåer om problem uppstår.

effective_cache_size:Ställ in summan av minne som är ledigt och cachelagrat som rapporteras med kommandot "free".

Kontrollpunktsinställningar

För PostgreSQL 9.4 och nedan:
checkpoint_segments:Ett antal checkpointsegment (16 megabyte vardera) för att ge Write Ahead Log-systemet. Standard är 3, och kan säkert ökas till 64 även för små databaser.

För PostgreSQL 9.5 och högre:
max_wal_size:Detta ersatte checkpoint_segments som en inställning. Standard är 1 GB och kan vara kvar här tills du behöver göra ytterligare ändringar.

Säkerhet

listen_address:Den här inställningen bestämmer vilka personliga IP-adresser/nätverkskort som ska lyssna på anslutningar på. I en enkel installation kommer det sannolikt bara att finnas en, medan mer avancerade nätverk kan ha flera kort för att ansluta till flera nätverk. * Betyder att lyssna på allt. Men om applikationen som kommer åt databasen ska leva på samma värd som själva databasen räcker det att behålla den som "localhost".

Loggning

Några grundläggande loggningsinställningar som inte kommer att överbelasta loggarna är följande.

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0