35. Grundläggande PostgreSQL-justering¶
PostgreSQL är ett mycket mångsidigt databassystem som kan köras effektivt i miljöer med mycket låga resurser och miljöer som delas med en mängd andra applikationer. För att säkerställa att den körs korrekt för många olika miljöer är standardkonfigurationen mycket konservativ och inte särskilt lämplig för en högpresterande produktionsdatabas. Lägg till det faktum att geospatiala databaser har andra användningsmönster och att data tenderar att bestå av färre, mycket större poster än icke-geospatiala databaser, så kan du se att standardkonfigurationen inte kommer att vara helt lämplig för våra syften.
Alla dessa konfigurationsparametrar kan redigeras i databasens konfigurationsfil postgresql.conf. Detta är en vanlig textfil som kan redigeras med valfri textredigerare. Ändringarna träder inte i kraft förrän servern startas om.
I det här avsnittet beskrivs några av de konfigurationsparametrar som kan justeras för att få en mer produktionsklar geospatial databas.
Observera
Dessa värden är endast rekommendationer; varje miljö kommer att skilja sig åt och tester krävs för att fastställa den optimala konfigurationen. Men det här avsnittet bör ge dig en bra start.
35.2. effective_cache_size¶
Förutom det minne som PostgreSQL avsätter för shared_buffers tar frågeplaneraren också hänsyn till hur många diskblock operativsystemet kan ha cachat som en del av dess virtuella filsystem. För system med stor mängd minne kan detta vara ganska stort. Den effective_cache_size är ungefär lika stor som maskinens minne, minus de shared_buffers, minus work_mem gånger det förväntade antalet anslutningar, minus det minne som krävs för andra processer som körs på maskinen, minus ca 1 GB för andra slumpmässiga behov hos operativsystemet. Databasen kommer inte att använda den extra cachen direkt, men den kommer att beräkna planer som förväntar sig att operativsystemet har cachat filsystemdata i ungefär lika mycket minne.
Standardvärde: typiskt 4GB
Rekommenderat värde: den mängd ”ledigt” minne som förväntas finnas i närheten under normala driftsförhållanden
35.3. work_mem¶
Definierar den mängd minne som interna sorteringsoperationer, indexeringsoperationer och hashtabeller kan förbruka innan databasen växlar till filer på disken. Detta värde definierar det tillgängliga minnet för varje operation; komplexa frågor kan ha flera sorterings- eller hashoperationer som körs parallellt, och varje ansluten session kan köra en fråga.
Därför måste du ta hänsyn till hur många anslutningar och hur komplexa de förväntade frågorna är innan du ökar detta värde. Fördelen** med att öka är att fler av dessa operationer, inklusive ORDER BY- och DISTINCT-klausuler, merge- och hash-joins, hash-baserad aggregering och hash-baserad bearbetning av underfrågor, kan utföras utan diskskrivning. Kostnaden** för att öka är minne som kommer att användas per anslutning, vilket kan vara ganska högt med produktionsnivåer av anslutningar.
Standardvärde: 1MB
Rekommenderat värde: 32 MB
35.4. maintenance_work_mem¶
Definierar mängden minne som används för underhållsoperationer, inklusive dammsugning, skapande av index och främmande nycklar. Eftersom dessa operationer inte är särskilt vanliga kommer ett högre värde bara att medföra en tillfällig kostnad och kan avsevärt påskynda underhållsaktiviteterna Denna parameter kan alternativt ökas för en enda session innan ett antal CREATE INDEX- eller VACUUM-anrop utförs enligt nedan.
SET maintenance_work_mem TO '128MB'; VACUUM ANALYZE; SET maintenance_work_mem TO '16MB';Standardvärde: 16MB
Rekommenderat värde: 128 MB
35.5. wal_buffers¶
Anger hur mycket minne som används för WAL-data (Write-Ahead Log). Write-ahead-loggar ger en högpresterande mekanism för att säkerställa dataintegritet. Under varje ändringskommando skrivs effekterna av ändringarna först till WAL-filerna och rensas sedan till disk. Först när WAL-filerna har rensats skrivs ändringarna till själva datafilerna. Detta gör att datafilerna kan skrivas till disken på ett optimalt och asynkront sätt samtidigt som det säkerställs att alla dataändringar kan återställas från WAL-filen i händelse av en krasch.
Storleken på denna buffert behöver bara vara tillräckligt stor för att rymma WAL-data för en enda typisk transaktion. Standardvärdet är ofta tillräckligt för de flesta data, men geospatiala data tenderar att vara mycket större. Därför rekommenderas att du ökar storleken på den här parametern.
Standardvärde: 64kB
Rekommenderat värde: 1 MB
35.6. checkpoint_segment¶
Detta värde anger det maximala antalet loggfilssegment (vanligtvis 16 MB) som kan fyllas mellan automatiska WAL-kontrollpunkter. En WAL-kontrollpunkt är en punkt i sekvensen av WAL-transaktioner där det garanteras att datafilerna har uppdaterats med all information före kontrollpunkten. Vid denna tidpunkt spolas alla smutsiga datasidor till disken och en kontrollpunktspost skrivs till loggfilen. Detta gör det möjligt för crash recovery-processen att hitta den senaste checkpoint-posten och använda alla följande loggsegment för att slutföra dataåterställningen.
Eftersom checkpoint-processen kräver att alla smutsiga datasidor spolas över till disk, skapar den en betydande I/O-belastning. Samma argument som ovan gäller; geospatiala data är tillräckligt stora för att skapa obalans i optimeringar som inte är geospatiala. Om du ökar det här värdet förhindras överdrivna kontrollpunkter, men det kan leda till att servern startar om långsammare vid en krasch.
Standardvärde: 3
Rekommenderat värde: 6
35.7. random_page_cost¶
Detta är ett enhetslöst värde som representerar kostnaden för en slumpmässig sidåtkomst från disk. Detta värde är relativt ett antal andra kostnadsparametrar, inklusive sekventiell sidåtkomst och CPU-driftskostnader. Det finns ingen patentlösning för det här värdet, men standardvärdet är i allmänhet konservativt och gäller för databaser som körs på roterande media. Kostnaden för slumpmässig åtkomst för SSD bör sättas ännu lägre.
Detta värde kan ställas in per session med kommandot SET random_page_cost TO 2.0, vilket kan vara användbart för att testa hur det påverkar frågeplanerna.
Standardvärde: 4.0
Rekommenderat värde: 2.0 för roterande media, 1,0 för SSD
35.8. seq_page_cost¶
Detta är den parameter som styr kostnaden för en sekventiell sidåtkomst. Det här värdet behöver i allmänhet inte justeras, men skillnaden mellan detta värde och random_page_cost påverkar i hög grad de val som görs av frågeplaneraren. Detta värde kan också ställas in per session.
Standardvärde: 1.0
Rekommenderat värde: 1.0
35.9. Ladda om konfigurationen¶
När dessa ändringar har gjorts sparar du ändringarna och laddar om konfigurationen. Det enklaste sättet att göra detta är att starta om PostgreSQL-tjänsten.
I pgAdmin högerklickar du på servern PostGIS (localhost:5432) och väljer Disconnect.
I Windows Services (
services.msc) högerklickar du på PostgreSQL och väljer Restart.Tillbaka i pgAdmin klickar du på servern igen och väljer Disconnect.
