Opsætning af et optimalt miljø for PostgreSQL

Velkommen til PostgreSQL, et kraftfuldt open source-databasesystem, der kan hoste alt fra et par megabyte kundedata til en lille by-virksomhed til hundredvis af terabyte 'big data' for multinationale selskaber. Uanset applikationen er det sandsynligt, at der vil være behov for noget opsætnings- og konfigurationshjælp for at gøre databasen klar til handling.

Når en ny server er installeret, er PostgreSQL's indstillinger meget minimale, da de er designet til at køre på den mindst mulige mængde hardware. Men de er meget sjældent optimale. Her vil vi gennemgå en grundlæggende opsætning for nye projekter, og hvordan man sætter PostgreSQL op til at køre mest optimalt på nye projekter.

Hosting

On-Premise Hosting

Med en on-premise database er den bedste mulighed for en bar metal-vært, da virtuelle maskiner generelt udfører langsommere, medmindre vi taler om high-end enterprise-niveau VM'er. Dette giver også mulighed for strammere kontrol over CPU-, hukommelses- og diskopsætninger. Dette kommer dog med behovet for at have en ekspert ved hånden (eller kontrakt) til at udføre servervedligeholdelse.

Sky

At være vært for en database i skyen kan være vidunderligt i nogle aspekter, eller et mareridt i andre. Medmindre den valgte cloud-platform er meget optimeret (hvilket generelt betyder højere pris), kan den have problemer med miljøer med højere belastning. Hold øje med, om cloud-serveren er delt eller dedikeret (dedikeret, hvilket tillader fuld ydeevne fra serveren til applikationen), samt niveauet af IOPS (Input/output Operations Per Second) leveret af en cloud-server. Når (eller hvis) applikationen vokser til det punkt, at størstedelen af ​​dataene ikke kan gemmes i hukommelsen, er hastigheden for diskadgang afgørende.

Generel værtsopsætning

De vigtigste søjler, der er nødvendige for pålideligt at opsætte PostgreSQL, er baseret på værtens CPU-, Hukommelses- og Disk-evner. Afhængigt af applikationens behov vil en tilstrækkelig vært samt en velafstemt PostgreSQL-konfiguration have en fantastisk indflydelse på databasesystemets ydeevne.

Valg af et operativsystem

PostgreSQL kan kompileres på de fleste Unix-lignende operativsystemer, såvel som Windows. Men ydeevne på Windows er ikke engang sammenlignelig med et Unix-lignende system, så medmindre det er for et lille smid væk-projekt, vil det at holde sig til et etableret Unix-lignende system være vejen at gå. Til denne diskussion holder vi os til Linux-baserede systemer.

Den tilsyneladende højest brugte Linux-distribution, der bruges til at hoste PostgreSQL, er et Red Hat-baseret system, såsom CentOS eller Scientific Linux, eller endda Red Hat selv. Da Red Hat og CentOS fokuserer på stabilitet og ydeevne, arbejder samfundet bag disse projekter hårdt for at sikre, at vigtige applikationer, såsom databaser, er på den mest sikre og mest pålidelige version af Linux som muligt.

BEMÆRK:Linux har en række kerneversioner, der ikke er optimale til at køre PostgreSQL, så de anbefales på det kraftigste at undgås, hvis det er muligt (især på applikationer, hvor topydelse er den yderste vigtighed). Benchmarks har vist, at antallet af transaktioner pr. sekund falder fra kerneversion 3.4 – 3.10, men gendannes og forbedres markant i kerne 3.12. Dette udelukker desværre at bruge CentOS 7, hvis man går CentOS-ruten. CentOS 6 er stadig en gyldig og understøttet version af operativsystemet, og CentOS 8 forventes at blive frigivet, før 6 ikke bliver understøttet.

Installation

Installation kan udføres enten efter kilde eller ved at bruge lagre, der vedligeholdes af enten den valgte distribution af Linux, eller endnu bedre, PostgreSQL Global Development Group (PGDG), som vedligeholder depoter til Red Hat-baserede systemer (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux og Fedora), samt pakker til Debian og Ubuntu. Brug af PGDG-pakkerne vil sikre, at opdateringer til PostgreSQL er tilgængelige for opdatering ved udgivelse, i stedet for at vente på, at Linux-distributionens indbyggede arkiver godkender og leverer dem.

CPU

I disse dage er det ikke svært at have flere kerner tilgængelige for en databasevært. PostgreSQL selv er først for nylig begyndt at tilføje multi-threading-funktioner på forespørgselsniveauet og vil blive meget bedre i de kommende år. Men selv uden disse nye og kommende forbedringer afføder PostgreSQL selv nye tråde for hver forbindelse til databasen af ​​en klient. Disse tråde vil i det væsentlige bruge en kerne, når de er aktive, så antallet af nødvendige kerner vil afhænge af niveauet af nødvendige samtidige forbindelser og samtidige forespørgsler.

En god baseline at starte ud med er et 4-kernesystem til en lille applikation. Forudsat at applikationer danser mellem at udføre forespørgsler og sove, kan et 4-kernesystem håndtere et par dusin forbindelser, før det bliver overbelastet. Tilføjelse af flere kerner vil hjælpe med at skalere med en stigende arbejdsbyrde. Det er ikke ualmindeligt, at meget store PostgreSQL-databaser har 48+ kerner til at betjene mange hundrede forbindelser.

Tip til indstilling: Selvom hyper-threading er tilgængelig, er transaktioner pr. sekund generelt højere, når hyper-threading er deaktiveret. For databaseforespørgsler, der ikke er for komplekse, men højere i frekvens, er flere kerner vigtigere end hurtigere kerner.

Hukommelse

Hukommelse er et ekstremt vigtigt aspekt for PostgreSQL's samlede ydeevne. Hovedindstillingen for PostgreSQL med hensyn til hukommelse er shared_buffers, som er en del af hukommelsen allokeret direkte til PostgreSQL-serveren til datacache. Jo højere sandsynligheden er for, at de nødvendige data findes i hukommelsen, jo hurtigere forespørgsler vender tilbage, og hurtigere forespørgsler betyder en mere effektiv CPU-kerneopsætning som diskuteret i det foregående afsnit.

Forespørgsler har også til tider brug for hukommelse til at udføre sorteringsoperationer på data, før de returneres til klienten. Dette bruger enten ekstra ad-hoc-hukommelse (adskilt fra shared_buffers) eller midlertidige filer på disken, hvilket er meget langsommere.

Tip til indstilling: Et grundlæggende udgangspunkt for at indstille shared_buffers er at sætte det til 1/4 af værdien af ​​tilgængelig system ram. Dette gør det muligt for operativsystemet også at lave sin egen caching af data, såvel som andre kørende processer end selve databasen.

Forøgelse af work_mem kan fremskynde sorteringsoperationer, men at øge det for meget kan tvinge værten til at løbe tør for hukommelse sammen, da værdisættet kan udsendes delvist eller fuldstændigt flere gange pr. forespørgsel. Hvis flere forespørgsler anmoder om flere hukommelsesblokke til sortering, kan det hurtigt tilføje op til mere hukommelse, end hvad der er tilgængeligt på værten. Hold det lavt, og hæv det langsomt, indtil ydelsen er, hvor det ønskes.

Brug 'free'-kommandoen (såsom 'free -h'), indstil effektiv_cache_size til summen af ​​hukommelse, der er ledig og cachelagret. Dette lader forespørgselsplanlæggeren vide, at niveauet af OS-cache kan være tilgængeligt, og køre bedre forespørgselsplaner.

Disk

Diskens ydeevne kan være en af ​​de vigtigere ting at overveje, når du opsætter et system. Input-/outputhastigheder er vigtige for store databelastninger eller for at hente enorme mængder data, der skal behandles. Det bestemmer også, hvor hurtigt PostgreSQL kan synkronisere hukommelse med disk for at holde hukommelsespuljen optimal.

Nogle forberedelser i diske kan hjælpe med øjeblikkelig at forbedre den potentielle ydeevne, samt fremtidssikre databasesystemet til vækst.

• Separate diske

  En ny installation af PostgreSQL vil oprette klyngens datamappe et sted på det primære (og muligvis eneste) tilgængelige drev på systemet.

  En grundlæggende opsætning med flere drev ville være at tilføje et separat drev (eller sæt drev via RAID). Det har den fordel, at al databaserelateret dataoverførsel fungerer på en anden I/O-kanal end hovedoperativsystemet. Det giver også databasen mulighed for at vokse uden frygt for utilstrækkelig plads, der forårsager problemer og fejl andre steder i operativsystemet.

  For databaser med en ekstrem mængde aktivitet kan PostgreSQL Transaction Log (xlog) biblioteket placeres på endnu et drev, der adskiller mere tung I/O til en anden kanal væk fra det primære OS såvel som hoveddatabiblioteket. Dette er en avanceret foranstaltning, der hjælper med at presse mere ydeevne ud af et system, som ellers kan være tæt på dets grænser.

• Brug af RAID

  Opsætning af RAID til databasedrevene beskytter ikke kun mod tab af data, det kan også forbedre ydeevnen, hvis du bruger den rigtige RAID-konfiguration. RAID 1 eller 10 anses generelt for at være de bedste, og 10 tilbyder paritet og samlet hastighed. RAID 5 har dog højere redundansniveauer, men lider af et betydeligt fald i ydeevnen på grund af den måde, den spreder data på flere diske. Planlæg den bedst tilgængelige mulighed med masser af plads til datavækst, og dette vil være en konfiguration, der ikke skal ændres ofte, hvis overhovedet.

• Brug af SSD

  Solid State-drev er vidunderlige for ydeevne, og hvis de opfylder budgettet, kan virksomhedens SSD'er gøre tunge databehandlingsarbejdsbelastninger nat og dag hurtigere. Mindre til mellemstore databaser med mindre til mellemstore arbejdsbelastninger kan være overdrevent, men når man kæmper for den mindste procentvise stigning på store applikationer, kan SSD være den store kugle.

Tip til indstilling: Vælg en drevopsætning, der er bedst til den aktuelle applikation og har masser af plads til at vokse med tiden, efterhånden som dataene stiger.

Hvis du bruger en SSD, vil indstilling af random_page_cost til 1,5 eller 2 (standarden er 4) være gavnligt for forespørgselsplanlæggeren, da tilfældig datahentning er meget hurtigere end set på roterende diske.

Indledende konfigurationsindstillinger

Når du opsætter PostgreSQL for første gang, er der en håndfuld konfigurationsindstillinger, der nemt kan ændres baseret på værtens magt. Da applikationen forespørger databasen over tid, kan specifik tuning udføres baseret på applikationens behov. Det vil dog være emnet for en separat tuning-blog.

Hukommelsesindstillinger

shared_buffers:Indstil til 1/4 af systemhukommelsen. Hvis systemet har mindre end 1 GB samlet hukommelse, skal du indstille til ~ 1/8 af den samlede systemhukommelse

work_mem:Standarden er 4MB, og kan endda være rigeligt til det pågældende program. Men hvis midlertidige filer bliver oprettet ofte, og disse filer er ret små (tivis af megabyte), kan det være værd at øge denne indstilling. En konservativ entry level-indstilling kan være (1/4. systemhukommelse / max_connections). Denne indstilling afhænger i høj grad af den faktiske adfærd og hyppigheden af ​​forespørgsler til databasen, så den bør kun øges med forsigtighed. Vær klar til at reducere det tilbage til tidligere niveauer, hvis der opstår problemer.

effective_cache_size:Indstil til summen af ​​hukommelse, der er ledig og cachelagret, rapporteret af 'free'-kommandoen.

Indstillinger for kontrolpunkt

For PostgreSQL 9.4 og derunder:
checkpoint_segments:Et antal checkpoint-segmenter (16 megabyte hver) for at give Write Ahead Log-systemet. Standarden er 3, og kan sikkert øges til 64 for selv små databaser.

For PostgreSQL 9.5 og nyere:
max_wal_size:Dette erstattede checkpoint_segments som en indstilling. Standarden er 1 GB og kan forblive her, indtil der er behov for yderligere ændringer.

Sikkerhed

listen_address:Denne indstilling bestemmer, hvilke personlige IP-adresser/netværkskort der skal lyttes til forbindelser på. I en simpel opsætning vil der sandsynligvis kun være ét, mens mere avancerede netværk kan have flere kort til at forbinde til flere netværk. * Betyder at lytte til alt. Men hvis applikationen, der får adgang til databasen, skal leve på samme vært som selve databasen, er det tilstrækkeligt at beholde den som 'localhost'.

Logføring

Nogle grundlæggende logningsindstillinger, der ikke vil overbelaste logfilerne, er som følger.

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