Een van de nuttiger
PostgreSQL-documentatie waaraan ik ooit heb gewerkt, is het afstemmen van uw PostgreSQL
Server. Toen dat werd geschreven in de zomer van 2008, een paar maanden na de
release van PostgreSQL 8.3, was het moeilijk om een soortgelijke gids te vinden die
zowel (relatief) beknopt als actueel was. Sindsdien hebben ikzelf en
vele andere PostgreSQL-bijdragers geholpen dat document up-to-date te houden
toen er wijzigingen in PostgreSQL werden aangebracht.
De interessante en nuttige trend
gedurende die periode is dat parameters steeds uit de set verdwijnen
waarover u zich zorgen moet maken. In PostgreSQL 8.2 was er een lange
lijst met parameters die u waarschijnlijk moest aanpassen voor goede prestaties
op een PostgreSQL-server:shared_buffers, Effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers en (bij gebruik van
partitionering) constraint_exclusion.
8.3 heeft autovacuüm standaard ingesteld op
aangezet met redelijk gedrag, samen met het verwijderen van een paar
achtergrondschrijverparameters die alleen maar problemen veroorzaakten (ze
nooit in de lijst terechtgekomen). 8.4 verwijderde de noodzaak voor de twee
max_fsm_* parameters, verhoogde default_statistics_target naar een veel
betere startwaarde, en maakte het instellen van constraint_exclusion
onnodig in de meest voorkomende gevallen. Dat zijn zes parameters minder
die u waarschijnlijk moet aanpassen.
Helaas maakte versie 9.0 de
serverconfiguratie alleen maar ingewikkelder. En nieuwere Linux-kernels hebben zelfs
het standaardgedrag naar achteren gedrukt. Beginnend met Linux-kernel
2.6.33, is de standaardwaarde die is gekozen voor wal_sync_method gewijzigd in
open_datasync. Dit blijkt verschrikkelijke prestatie
implicaties te hebben voor PostgreSQL, vooral in combinatie met de lage
standaardinstelling voor wal_buffers in de server.
Maar de opmars naar een beter standaard
gedrag is onlangs hervat voor wat uiteindelijk de bedoeling is
PostgreSQL 9.1. Tijdens de laatste CommitFest is er een patch ontstaan Marti
Raudsepp om het wal_sync_method-probleem op te lossen, werd gepleegd
na een aantal zware argumenten over welke vorm die verandering zou moeten aannemen.
Ontdekken dat deze gedragsverandering PostgreSQL helemaal verbrak
br />bij het draaien op ext4 met de optie "data=journal" hielp het
om hier standaard de juiste beslissing te nemen.
Twee parameters die ik niet aanbeveel
in de meeste gevallen aan te raken, zijn commit_siblings en commit_delay,
artefacten van een oudere poging om de prestaties te verbeteren op systemen met
langzame commit-tijden (waaronder de meeste systemen die geen
door batterijen ondersteunde schrijfcache hebben om dat gebied te versnellen). Tegenwoordig
het uitschakelen van de parameter synchronous_commit die in 8.3 is geïntroduceerd,
is hier veel waarschijnlijker. Hoewel het onwaarschijnlijk is dat de
prestaties hiervan zullen verbeteren, hebben mensen die ze proberen in te stellen meer dan
noodzakelijk geleden onder de nadelen van die beslissing. Het
gedrag in het slechtste geval is hier aanzienlijk verbeterd in een patch die ik heb geschreven om de logica van de besturing van deze parameters te optimaliseren.
En deze week is de laatste parameter die
in de meeste gevallen effectief wordt geëlimineerd, wal_buffers. Een wijziging die ik
heb voorgesteld, is doorgevoerd om deze automatisch in te stellen als een percentage van de grootte (ongeveer 3%)
toegewezen aan de normaal veel grotere parameters voor shared_buffers.
Dit stelt de waarde van wal_buffers in op de normale bovengrens van zijn
effectieve bereik, 16 MB, zodra u ten minste 512 MB aan
shared_buffers heeft toegewezen. En als je shared_buffers hebt verhoogd van de kleine
standaard, krijg je een overeenkomstige verbetering in deze
belangrijke prestatieparameter voor commits. Je zult je
je uiterste best moeten doen om de instelling van deze parameter te verbreken om de slechte
situaties die mogelijk waren in eerdere versies aan te pakken.
De hoeveelheid configuratie die u
standaard aan de server moet doen, wordt altijd minder ingewikkeld
br />de moeite waard, en het is een welkome verandering om te zien dat parameters van de kritieke lijst verdwijnen. Wat is het volgende? De kernproblemen met het toewijzen van
gedeeld geheugen op UNIX-afgeleide besturingssystemen, met name Linux,
maken het erg moeilijk om gedeelde_buffers te elimineren. En zorgen
over de server die het systeem overneemt, beperken de mogelijkheid
om automatisch parameters zoals work_mem in het juiste bereik in te stellen.
Enkele voorstellen voor een beter beheer van de werkgeheugenpool zijn
>suggereerde, zodat men enige verbetering zou kunnen zien.
De volgende parameter die ik op het oog heb is
checkpoint_segments. Na het toevoegen van alleen extra logboekregistratie in dit gebied in
de laatste CommitFest, zijn er enkele verbeteringen in dit gebied die bijna
verplicht zich nu inzetten om het gedrag van checkpoints daadwerkelijk te verbeteren. Ik hoop
uiteindelijk over te schakelen op het afstemmen van checkpoints om strikt gecontroleerd te worden
via tijdgeoriënteerde parameters, in plaats van gebruikers te verplichten
de mechanica te begrijpen van hoe het vooruitschrijven-logboek werkt om de
br />systeem. Er zijn hier nog te veel lelijke situaties om
dat op tijd voor 9.1 te doen, maar het automatisch instellen van het aantal segmenten is
mogelijk om te targeten op 9.2.