Einer der nützlichsten Teile der
PostgreSQL-Dokumentation, an der ich je gearbeitet habe, ist Tuning Your PostgreSQL
Server. Als das im Sommer 2008 geschrieben wurde, ein paar Monate nach der
Veröffentlichung von PostgreSQL 8.3, war es schwierig, eine ähnliche Anleitung zu finden, die
sowohl (relativ) prägnant als auch aktuell war. Seitdem haben ich und
viele andere PostgreSQL-Mitarbeiter dabei geholfen, dieses Dokument
auf dem neuesten Stand zu halten, da Änderungen an PostgreSQL vorgenommen wurden.
Der interessante und hilfreiche Trend
während dieser Zeit ist, dass Parameter immer wieder aus dem Set verschwinden
von denen, um die Sie sich Sorgen machen müssen. In PostgreSQL 8.2 gab es eine lange
Liste von Parametern, die Sie für eine gute Leistung
auf einem PostgreSQL-Server wahrscheinlich anpassen mussten:shared_buffers, Effective_Cache_Size,
Checkpoint_Segments, Autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers und (bei Verwendung von
Partitionierung) Constraint_Exclusion.
8.3 hat das Autovacuum standardmäßig
mit angemessenem Verhalten aktiviert, zusammen mit dem Entfernen einiger
Hintergrund-Writer-Parameter, die nur Ärger machten (sie
hatten es nie auf die Liste geschafft). 8.4 beseitigte die Notwendigkeit der beiden
max_fsm_* Parameter, erhöhte default_statistics_target auf einen viel
besseren Startwert und machte das Setzen von constraint_exclusion
in den häufigsten Fällen überflüssig. Das sind sechs Parameter weniger,
die Sie wahrscheinlich anpassen müssen.
Leider hat Version 9.0 die Serverkonfiguration
nur komplizierter gemacht. Und neuere Linux-Kernel haben sogar
das Standardverhalten nach hinten verschoben. Beginnend mit dem Linux-Kernel
2.6.33 wurde der für wal_sync_method ausgewählte Standardwert in
open_datasync geändert. Dies hat schreckliche
Auswirkungen auf die Leistung von PostgreSQL, insbesondere in Kombination mit der niedrigen
Standardeinstellung für wal_buffers im Server.
Aber der Marsch in Richtung besseres Standardverhalten
wurde kürzlich wieder aufgenommen für das, was letztendlich geplant ist
PostgreSQL 9.1. Während des letzten CommitFests wurde ein Patch von Marti
Raudsepp zur Behebung des wal_sync_method-Problems übernommen
nach einigen heftigen Auseinandersetzungen darüber, welche Form diese Änderung annehmen sollte.
Die Entdeckung, dass diese Verhaltensänderung PostgreSQL vollständig zerstörte
bei der Ausführung auf ext4 mit der Option „data=journal“ hat geholfen,
hier standardmäßig das Richtige zu tun.
Zwei Parameter, die ich nicht empfehle
in den meisten Fällen zu berühren, sind commit_siblings und commit_delay,
Artefakte eines älteren Versuchs, die Leistung auf Systemen mit
langsamen Commit-Zeiten zu verbessern (was die meisten Systeme einschließt, die keinen
batteriegestützten Schreibcache zum Beschleunigen dieses Bereichs haben). Heutzutage
hilft hier das Abschalten des in 8.3 eingeführten synchronen_commit-Parameters
viel eher. Während diese wahrscheinlich nicht die Leistung
verbessern, haben Leute, die versuchen, sie einzustellen, mehr als
unter den Nachteilen dieser Entscheidung gelitten. Das Worst-Case-Verhalten
hier wurde in einem Patch, den ich geschrieben habe, erheblich verbessert, um die Ausführung der Logik zu optimieren, die diese Parameter steuern.
Und diese Woche ist der neueste Parameter, der
in den meisten Fällen effektiv eliminiert werden soll, wal_buffers. Eine Änderung, die ich
vorgeschlagen habe, wurde vorgenommen, um dies automatisch als Prozentsatz der Größe (etwa 3%) festzulegen,
die den normalerweise viel größeren shared_buffers-Parametern zugewiesen wird.
Dies setzt den Wert von wal_buffers auf den normale Obergrenze des
effektiven Bereichs, 16 MB, sobald Ihnen mindestens 512 MB für
shared_buffers zugewiesen wurden. Und wenn Sie shared_buffers von seinem winzigen
Standardwert überhaupt erhöht haben, erhalten Sie eine entsprechende Verbesserung dieses
wichtigen Commit-Leistungsparameters. Sie müssen sich
anstrengen, um die Einstellung dieses Parameters zu unterbrechen, um die schlechten
Situationen zu treffen, die in früheren Versionen möglich waren.
Dass der Umfang der Konfiguration, die Sie
für den Server vornehmen müssen, standardmäßig weniger kompliziert wird, ist immer
lohnt sich, und zu sehen, wie Parameter aus der kritischen Liste verschwinden, ist
eine willkommene Abwechslung. Was kommt als nächstes? Die Kernprobleme bei der Zuweisung von
gemeinsam genutztem Speicher auf von UNIX abgeleiteten Betriebssystemen, insbesondere Linux,
machen es sehr schwierig, shared_buffers zu eliminieren. Und Bedenken,
dass der Server das System übernehmen könnte, schränken die Möglichkeit ein,
Parameter wie work_mem automatisch auf den richtigen Bereich zu setzen.
Einige Vorschläge zur besseren Verwaltung des Arbeitsspeicherpools wurden
>vorgeschlagen, damit man vielleicht eine Verbesserung sieht.
Der nächste Parameter, den ich im Auge habe, ist
checkpoint_segments. Nachdem in diesem Bereich im
letzten CommitFest nur eine zusätzliche Protokollierung hinzugefügt wurde, gibt es einige Verbesserungen in diesem Bereich,
die sich jetzt dem Commit nähern, um das Checkpoint-Verhalten tatsächlich zu verbessern. Ich hoffe, dass
das Checkpoint-Tuning irgendwann so umgestellt wird, dass es streng kontrolliert wird
über zeitorientierte Parameter, anstatt von den Benutzern zu verlangen,
die Mechanik zu verstehen, wie das Write-Ahead-Protokoll funktioniert, um das
System. Hier sind immer noch zu viele hässliche Situationen möglich, um
das rechtzeitig für 9.1 zu tun, aber das automatische Festlegen der Anzahl der Segmente ist
als Ziel für 9.2 möglich.
