Een optimale omgeving instellen voor PostgreSQL

Welkom bij PostgreSQL, een krachtig open source databasesysteem dat alles kan hosten, van een paar megabytes aan klantgegevens voor een klein bedrijf tot honderden terabytes aan 'big data' voor multinationale ondernemingen. Ongeacht de toepassing is het waarschijnlijk dat enige hulp bij het instellen en configureren nodig is om de database gereed te maken voor actie.

Wanneer een nieuwe server wordt geïnstalleerd, zijn de instellingen van PostgreSQL zeer minimaal, omdat ze zijn ontworpen om op zo min mogelijk hardware te draaien. Ze zijn echter zelden optimaal. Hier bespreken we een basisconfiguratie voor nieuwe projecten en hoe u PostgreSQL kunt instellen om zo optimaal mogelijk te werken bij nieuwe projecten.

Hosting

On-Premise Hosting

Met een on-premise database is de beste optie voor een bare-metal host, aangezien virtuele machines over het algemeen langzamer presteren, tenzij we het hebben over hoogwaardige VM's op ondernemingsniveau. Dit zorgt ook voor een strakkere controle over de CPU-, geheugen- en schijfinstellingen. Dit gaat echter gepaard met de noodzaak om een ​​expert (of contract) bij de hand te hebben om serveronderhoud uit te voeren.

Cloud

Het hosten van een database in de cloud kan in sommige aspecten geweldig zijn, of een nachtmerrie in andere. Tenzij het gekozen cloudplatform sterk geoptimaliseerd is (wat over het algemeen een hogere prijs betekent), kan het problemen hebben met omgevingen met een hogere belasting. Houd in de gaten of de cloudserver al dan niet gedeeld of gereserveerd is (dedicated waardoor volledige prestaties van de server voor de applicatie mogelijk zijn), evenals het niveau van IOPS (Input/output Operations Per Second) dat door een cloudserver wordt geleverd. Wanneer (of als) de applicatie zo groeit dat de meeste gegevens niet in het geheugen kunnen worden opgeslagen, is de snelheid van schijftoegang cruciaal.

Algemene hostconfiguratie

De belangrijkste pijlers die nodig zijn om PostgreSQL betrouwbaar in te stellen, zijn gebaseerd op de CPU-, geheugen- en schijfcapaciteiten van de host. Afhankelijk van de applicatiebehoeften, zullen een voldoende host en een goed afgestemde PostgreSQL-configuratie een verbazingwekkende impact hebben op de prestaties van het databasesysteem.

Een besturingssysteem kiezen

PostgreSQL kan worden gecompileerd op de meeste Unix-achtige besturingssystemen, evenals op Windows. De prestaties op Windows zijn echter niet eens vergelijkbaar met een Unix-achtig systeem, dus tenzij het voor een klein wegwerpproject is, is vasthouden aan een gevestigd Unix-achtig systeem de beste keuze. Voor deze discussie houden we het bij op Linux gebaseerde systemen.

De schijnbaar meest gebruikte Linux-distributie die wordt gebruikt voor het hosten van PostgreSQL is een op Red Hat gebaseerd systeem, zoals CentOS of Scientific Linux, of zelfs Red Hat zelf. Aangezien Red Hat en CentOS zich richten op stabiliteit en prestaties, werkt de gemeenschap achter deze projecten hard om ervoor te zorgen dat belangrijke applicaties, zoals databases, op de veiligste en meest betrouwbare versie van Linux draaien.

OPMERKING:Linux heeft een reeks kernelversies die niet optimaal zijn voor het uitvoeren van PostgreSQL, dus het wordt ten zeerste aangeraden deze indien mogelijk te vermijden (vooral bij toepassingen waarbij topprestaties van het grootste belang zijn). Benchmarks hebben aangetoond dat het aantal transacties per seconde daalt vanaf kernelversie 3.4 – 3.10, maar herstelt en aanzienlijk verbetert in kernel 3.12. Dit sluit helaas het gebruik van CentOS 7 uit als je de CentOS-route volgt. CentOS 6 is nog steeds een geldige en ondersteunde versie van het besturingssysteem en CentOS 8 zal naar verwachting worden uitgebracht voordat 6 niet meer wordt ondersteund.

Installatie

Installatie kan worden gedaan via de bron of met behulp van opslagplaatsen die worden onderhouden door de gekozen Linux-distributie, of beter nog, de PostgreSQL Global Development Group (PGDG), die opslagplaatsen onderhoudt voor op Red Hat gebaseerde systemen (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux en Fedora), evenals pakketten voor Debian en Ubuntu. Het gebruik van de PGDG-pakketten zorgt ervoor dat updates voor PostgreSQL beschikbaar zijn voor update bij release, in plaats van te wachten op de ingebouwde opslagplaatsen van de Linux-distributie om ze goed te keuren en aan te bieden.

CPU

Tegenwoordig is het niet moeilijk om meerdere cores beschikbaar te hebben voor een databasehost. PostgreSQL zelf is pas onlangs begonnen met het toevoegen van multi-threading-mogelijkheden op queryniveau en zal de komende jaren veel beter worden. Maar zelfs zonder deze nieuwe en aanstaande verbeteringen, brengt PostgreSQL zelf nieuwe threads voort voor elke verbinding met de database door een client. Deze threads gebruiken in wezen een core als ze actief zijn, dus het aantal benodigde cores hangt af van het niveau van de benodigde gelijktijdige verbindingen en gelijktijdige query's.

Een goede basis om mee te beginnen is een 4-core systeem voor een kleine applicatie. Ervan uitgaande dat applicaties een dans doen tussen het uitvoeren van query's en slapen, kan een 4-coresysteem een ​​paar dozijn verbindingen aan voordat het overbelast raakt. Door meer kernen toe te voegen, kunt u schalen met een toenemende werklast. Het is niet ongebruikelijk dat zeer grote PostgreSQL-databases 48+ cores hebben om vele honderden verbindingen te bedienen.

Afstemmingstips: Zelfs als hyperthreading beschikbaar is, zijn transacties per seconde over het algemeen hoger wanneer hyperthreading is uitgeschakeld. Voor databasequery's die niet te complex zijn, maar met een hogere frequentie, zijn meer cores belangrijker dan snellere cores.

Geheugen

Geheugen is een uiterst belangrijk aspect voor de algehele prestaties van PostgreSQL. De belangrijkste instelling voor PostgreSQL in termen van geheugen is shared_buffers, een stuk geheugen dat rechtstreeks aan de PostgreSQL-server wordt toegewezen voor gegevenscaching. Hoe groter de kans dat de benodigde gegevens in het geheugen blijven, hoe sneller query's terugkeren, en snellere query's betekenen een efficiëntere CPU-kernconfiguratie, zoals besproken in de vorige sectie.

Query's hebben soms ook geheugen nodig om sorteerbewerkingen op gegevens uit te voeren voordat deze worden teruggestuurd naar de client. Dit gebruikt ofwel extra ad-hoc geheugen (los van shared_buffers), of tijdelijke bestanden op schijf, wat veel langzamer is.

Afstemmingstips: Een basisbeginpunt voor het instellen van shared_buffers is om het in te stellen op 1/4 van de waarde van de beschikbare systeemram. Hierdoor kan het besturingssysteem ook zijn eigen gegevens in de cache opslaan, evenals alle andere lopende processen dan de database zelf.

Het verhogen van work_mem kan sorteerbewerkingen versnellen, maar te veel verhogen kan ervoor zorgen dat de host geen geheugen meer heeft, omdat de waardeset meerdere keren per query gedeeltelijk of volledig kan worden uitgegeven. Als meerdere query's meerdere geheugenblokken vragen om te sorteren, kan dit snel oplopen tot meer geheugen dan wat beschikbaar is op de host. Houd het laag en verhoog het langzaam totdat de prestaties zijn waar gewenst.

Gebruik het 'free' commando (zoals 'free -h'), stel effective_cache_size in op de som van het geheugen dat vrij en in de cache is. Hierdoor weet de queryplanner welk niveau van OS-caching mogelijk beschikbaar is en kan hij betere queryplannen uitvoeren.

Schijf

Schijfprestaties kunnen een van de belangrijkste dingen zijn om te overwegen bij het opzetten van een systeem. Invoer-/uitvoersnelheden zijn belangrijk voor grote gegevensbelastingen of het ophalen van grote hoeveelheden gegevens die moeten worden verwerkt. Het bepaalt ook hoe snel PostgreSQL geheugen met schijf kan synchroniseren om de geheugenpool optimaal te houden.

Enige voorbereiding in schijven kan helpen om de potentiële prestaties onmiddellijk te verbeteren en het databasesysteem toekomstbestendig te maken voor groei.

• Afzonderlijke schijven

  Een nieuwe installatie van PostgreSQL zal de gegevensmap van het cluster ergens op de belangrijkste (en mogelijk enige) beschikbare schijf op het systeem maken.

  Een basisconfiguratie met meer schijven zou het toevoegen van een afzonderlijke schijf (of een set schijven via RAID) zijn. Het heeft het voordeel dat alle databasegerelateerde gegevensoverdracht op een ander I/O-kanaal werkt dan het hoofdbesturingssysteem. Het zorgt er ook voor dat de database kan groeien zonder angst voor onvoldoende ruimte die problemen en fouten elders in het besturingssysteem veroorzaakt.

  Voor databases met een extreme hoeveelheid activiteit kan de PostgreSQL Transaction Log (xlog)-directory op nog een andere schijf worden geplaatst, waardoor zwaardere I/O wordt gescheiden naar een ander kanaal, weg van het hoofdbesturingssysteem en de hoofdgegevensdirectory. Dit is een geavanceerde maatregel die helpt om meer prestaties uit een systeem te persen, dat anders tegen zijn limiet zou kunnen komen.

• RAID gebruiken

  Het instellen van RAID voor de databaseschijven beschermt niet alleen tegen gegevensverlies, het kan ook de prestaties verbeteren als de juiste RAID-configuratie wordt gebruikt. RAID 1 of 10 wordt over het algemeen als de beste beschouwd, en 10 biedt pariteit en algehele snelheid. RAID 5 heeft echter hogere niveaus van redundantie, maar lijdt onder een aanzienlijke prestatievermindering vanwege de manier waarop het gegevens over meerdere schijven verspreidt. Plan de best beschikbare optie met voldoende ruimte voor gegevensgroei, en dit zal een configuratie zijn die niet vaak of helemaal niet hoeft te worden gewijzigd.

• SSD gebruiken

  Solid State-schijven zijn geweldig voor prestaties, en als ze binnen het budget passen, kunnen SSD's voor ondernemingen de zware gegevensverwerkingswerklast dag en nacht sneller maken. Kleinere tot middelgrote databases met kleinere tot middelgrote workloads kunnen overkill zijn, maar als je vecht voor de kleinste procentuele toename van grote applicaties, kan SSD dat wondermiddel zijn.

Afstemmingstips: Kies een schijfconfiguratie die het beste is voor de betreffende toepassing en die voldoende ruimte heeft om met de tijd mee te groeien naarmate de gegevens toenemen.

Als u een SSD gebruikt, is het gunstig voor de queryplanner om random_page_cost in te stellen op 1,5 of 2 (de standaardwaarde is 4), aangezien het willekeurig ophalen van gegevens veel sneller gaat dan op draaiende schijven.

Initiële configuratie-instellingen

Wanneer u PostgreSQL voor de eerste keer instelt, zijn er een handvol configuratie-instellingen die eenvoudig kunnen worden gewijzigd op basis van de kracht van de host. Omdat de applicatie de database in de loop van de tijd doorzoekt, kan er specifieke afstemming plaatsvinden op basis van de behoeften van de applicatie. Dat zal echter het onderwerp zijn voor een aparte tuningblog.

Geheugeninstellingen

shared_buffers:ingesteld op 1/4 van het systeemgeheugen. Als het systeem minder dan 1 GB totaal geheugen heeft, stel dan in op ~ 1/8e van het totale systeemgeheugen

work_mem:de standaardwaarde is 4 MB en kan zelfs voldoende zijn voor de betreffende toepassing. Maar als er vaak tijdelijke bestanden worden gemaakt en die bestanden vrij klein zijn (tientallen megabytes), kan het de moeite waard zijn om deze instelling te verhogen. Een conservatieve instapinstelling kan zijn (1/4e systeemgeheugen / max_connections). Deze instelling is sterk afhankelijk van het daadwerkelijke gedrag en de frequentie van query's naar de database, dus moet voorzichtig worden verhoogd. Wees klaar om het terug te brengen naar eerdere niveaus als er problemen optreden.

effectieve_cache_size:Stel in op de som van het geheugen dat vrij is en in de cache wordt gerapporteerd door het 'free'-commando.

Checkpoint-instellingen

Voor PostgreSQL 9.4 en lager:
checkpoint_segments:een aantal checkpoint-segmenten (elk 16 megabytes) om het Write Ahead Log-systeem te geven. De standaardwaarde is 3 en kan veilig worden verhoogd tot 64, zelfs voor kleine databases.

Voor PostgreSQL 9.5 en hoger:
max_wal_size:dit vervangt checkpoint_segments als instelling. De standaardwaarde is 1 GB en kan hier blijven totdat er verdere wijzigingen nodig zijn.

Beveiliging

listen_address:Deze instelling bepaalt op welke persoonlijke IP-adressen / netwerkkaarten naar verbindingen moet worden geluisterd. In een eenvoudige installatie zal er waarschijnlijk maar één zijn, terwijl meer geavanceerde netwerken mogelijk meerdere kaarten hebben om verbinding te maken met meerdere netwerken. * Betekent luisteren naar alles. Als de toepassing die toegang heeft tot de database echter op dezelfde host moet staan ​​als de database zelf, is het voldoende om deze als 'localhost' te behouden.

Logboekregistratie

Enkele basisinstellingen voor logboekregistratie die de logboeken niet overbelasten, zijn als volgt.

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