Verwenden Sie zunächst immer die neueste Version von PostgreSQL. Leistungsverbesserungen kommen immer, also verschwenden Sie wahrscheinlich Ihre Zeit, wenn Sie eine alte Version optimieren. Beispielsweise verbessert PostgreSQL 9.2 die Geschwindigkeit von TRUNCATE erheblich und fügt natürlich Index-Only-Scans hinzu. Selbst kleinere Veröffentlichungen sollten immer befolgt werden; siehe Versionsrichtlinie.
Don'ts
NICHT Legen Sie einen Tablespace auf eine RAM-Disk oder einen anderen nicht dauerhaften Speicher.
Wenn Sie einen Tablespace verlieren, kann die gesamte Datenbank beschädigt und ohne erheblichen Aufwand schwer zu verwenden sein. Dies hat nur sehr wenige Vorteile im Vergleich zur Verwendung von UNLOGGED Tabellen und sowieso viel RAM für den Cache haben.
Wenn Sie wirklich ein Ramdisk-basiertes System wollen, initdb ein ganz neuer Cluster auf der Ramdisk von initdb Erstellen Sie eine neue PostgreSQL-Instanz auf der Ramdisk, sodass Sie eine vollständig verfügbare PostgreSQL-Instanz haben.
PostgreSQL-Serverkonfiguration
Beim Testen können Sie Ihren Server für einen nicht dauerhaften, aber schnelleren Betrieb konfigurieren.
Dies ist eine der einzig akzeptablen Verwendungen für fsync=off Einstellung in PostgreSQL. Diese Einstellung weist PostgreSQL so ziemlich an, sich nicht mit geordneten Schreibvorgängen oder anderen unangenehmen Datenintegritäts- und Absturzsicherheitskrams zu beschäftigen, und gibt ihm die Erlaubnis, Ihre Daten vollständig zu zerstören, wenn Sie die Stromversorgung verlieren oder das Betriebssystem abstürzt.
Natürlich sollten Sie fsync=off niemals aktivieren in der Produktion, es sei denn, Sie verwenden Pg als temporäre Datenbank für Daten, die Sie von woanders neu generieren können. Wenn und nur wenn Sie fsync ausschalten, können Sie auch full_page_writes einschalten ab, da es dann nichts mehr bringt. Beachten Sie, dass fsync=off und full_page_writes bewerben Sie sich beim Cluster Stufe, also betreffen sie alle Datenbanken in Ihrer PostgreSQL-Instanz.
Für den Produktionseinsatz können Sie möglicherweise synchronous_commit=off verwenden und setze ein commit_delay , da Sie viele der gleichen Vorteile wie fsync=off erhalten ohne das riesige Datenkorruptionsrisiko. Sie haben ein kleines Zeitfenster für den Verlust aktueller Daten, wenn Sie asynchrones Commit aktivieren - aber das war's.
Wenn Sie die Möglichkeit haben, die DDL leicht zu ändern, können Sie auch UNLOGGED verwenden Tabellen in Pg 9.1+, um die WAL-Protokollierung vollständig zu vermeiden und einen echten Geschwindigkeitsschub auf Kosten der Tabellen zu erzielen, die bei einem Serverabsturz gelöscht werden. Es gibt keine Konfigurationsoption, um alle Tabellen unprotokolliert zu machen, sie muss während CREATE TABLE gesetzt werden . Dies ist nicht nur gut zum Testen, sondern auch praktisch, wenn Sie Tabellen voller generierter oder unwichtiger Daten in einer Datenbank haben, die ansonsten Dinge enthält, die Sie für Ihre Sicherheit benötigen.
Überprüfen Sie Ihre Protokolle und prüfen Sie, ob Sie Warnungen zu zu vielen Checkpoints erhalten. Wenn ja, sollten Sie Ihre checkpoint_segments erhöhen. Möglicherweise möchten Sie auch Ihr checkpoint_completion_target optimieren, um Schreibvorgänge zu glätten.
Optimieren Sie shared_buffers passend zu Ihrem Arbeitspensum. Dies ist betriebssystemabhängig, hängt davon ab, was sonst noch auf Ihrem Computer vor sich geht, und erfordert einige Versuche und Irrtümer. Die Voreinstellungen sind äußerst konservativ. Möglicherweise müssen Sie die maximale Grenze des gemeinsam genutzten Speichers des Betriebssystems erhöhen, wenn Sie shared_buffers erhöhen auf PostgreSQL 9.2 und darunter; 9.3 und höher hat geändert, wie sie gemeinsam genutzten Speicher verwenden, um dies zu vermeiden.
Wenn Sie nur ein paar Verbindungen verwenden, die viel Arbeit erledigen, erhöhen Sie work_mem um ihnen mehr RAM zu geben, mit dem sie spielen können usw. Achten Sie auf einen zu hohen work_mem Die Einstellung kann zu Problemen mit nicht genügend Arbeitsspeicher führen, da sie pro Sortierung und nicht pro Verbindung erfolgt, sodass eine Abfrage viele verschachtelte Sortierungen haben kann. Du nur wirklich müssen work_mem erhöhen wenn Sie in EXPLAIN sehen können, dass Sortierungen auf die Festplatte überlaufen oder mit den log_temp_files protokolliert Einstellung (empfohlen), aber ein höherer Wert kann Pg auch dazu bringen, intelligentere Pläne auszuwählen.
Wie von einem anderen Poster hier gesagt, ist es ratsam, das xlog und die Haupttabellen/-indizes nach Möglichkeit auf separaten Festplatten abzulegen. Separate Partitionen sind ziemlich sinnlos, Sie möchten wirklich separate Laufwerke. Diese Trennung hat viel weniger Nutzen, wenn Sie mit fsync=off arbeiten und fast keine, wenn Sie UNLOGGED verwenden Tabellen.
Optimieren Sie schließlich Ihre Abfragen. Stellen Sie sicher, dass Ihre random_page_cost und seq_page_cost die Leistung Ihres Systems widerspiegeln, achten Sie auf Ihre effective_cache_size korrekt ist usw. Verwenden Sie EXPLAIN (BUFFERS, ANALYZE) um einzelne Abfragepläne zu untersuchen, und schalten Sie den auto_explain ein Modul ein, um alle langsamen Abfragen zu melden. Sie können die Abfrageleistung häufig erheblich verbessern, indem Sie einfach einen geeigneten Index erstellen oder die Kostenparameter optimieren.
AFAIK, es gibt keine Möglichkeit, eine ganze Datenbank oder einen Cluster als UNLOGGED festzulegen . Es wäre interessant, das zu können. Erwägen Sie eine Anfrage auf der PostgreSQL-Mailingliste.
Host-OS-Tuning
Es gibt auch einige Optimierungen, die Sie auf Betriebssystemebene vornehmen können. Das Wichtigste, was Sie vielleicht tun möchten, ist, das Betriebssystem davon zu überzeugen, Schreibvorgänge nicht aggressiv auf die Festplatte zu löschen, da es Ihnen wirklich egal ist, wann/ob sie es auf die Festplatte schaffen.
Unter Linux können Sie dies mit dirty_* des virtuellen Speichersubsystems steuern Einstellungen wie dirty_writeback_centisecs .
Das einzige Problem beim Optimieren der Writeback-Einstellungen auf zu locker ist, dass ein Flush durch ein anderes Programm dazu führen kann, dass alle angesammelten Puffer von PostgreSQL ebenfalls geleert werden, was zu großen Verzögerungen führt, während alles beim Schreiben blockiert. Möglicherweise können Sie dies abmildern, indem Sie PostgreSQL auf einem anderen Dateisystem ausführen, aber einige Leerungen erfolgen möglicherweise auf Geräteebene oder auf der Ebene des gesamten Hosts, nicht auf Dateisystemebene, sodass Sie sich nicht darauf verlassen können.
Bei dieser Optimierung müssen Sie wirklich mit den Einstellungen herumspielen, um zu sehen, was für Ihre Arbeitslast am besten funktioniert.
Bei neueren Kerneln möchten Sie vielleicht sicherstellen, dass vm.zone_reclaim_mode auf Null gesetzt, da dies aufgrund von Interaktionen damit, wie PostgreSQL shared_buffers verwaltet, schwerwiegende Leistungsprobleme mit NUMA-Systemen (heutzutage die meisten Systeme) verursachen kann .
Abfrage- und Workload-Tuning
Dies sind Dinge, die Codeänderungen erfordern; sie passen vielleicht nicht zu dir. Einige Dinge können Sie vielleicht anwenden.
Wenn Sie die Arbeit nicht in größere Transaktionen bündeln, beginnen Sie damit. Viele kleine Transaktionen sind teuer, daher sollten Sie Dinge bündeln, wann immer dies möglich und praktikabel ist. Wenn Sie asynchrones Commit verwenden, ist dies weniger wichtig, aber dennoch sehr zu empfehlen.
Verwenden Sie nach Möglichkeit temporäre Tabellen. Sie erzeugen keinen WAL-Verkehr, daher sind sie viel schneller für Einfügungen und Aktualisierungen. Manchmal lohnt es sich, einen Haufen Daten in eine temporäre Tabelle zu schlürfen, sie nach Bedarf zu manipulieren und dann INSERT INTO ... SELECT ... auszuführen um es an den Abschlusstisch zu kopieren. Beachten Sie, dass temporäre Tabellen pro Sitzung gelten; Wenn Ihre Sitzung endet oder Sie Ihre Verbindung verlieren, verschwindet die temporäre Tabelle und keine andere Verbindung kann den Inhalt der temporären Tabelle(n) einer Sitzung sehen.
Wenn Sie PostgreSQL 9.1 oder neuer verwenden, können Sie UNLOGGED verwenden Tabellen für Daten, deren Verlust Sie sich leisten können, wie z. B. den Sitzungsstatus. Diese sind über verschiedene Sitzungen hinweg sichtbar und werden zwischen Verbindungen beibehalten. Sie werden abgeschnitten, wenn der Server unsauber heruntergefahren wird, sodass sie nicht für Dinge verwendet werden können, die Sie nicht neu erstellen können, aber sie eignen sich hervorragend für Caches, materialisierte Ansichten, Zustandstabellen usw.
Im Allgemeinen sollten Sie DELETE FROM blah; nicht verwenden . Verwenden Sie TRUNCATE TABLE blah; stattdessen; Es ist viel schneller, wenn Sie alle Zeilen in einer Tabelle ausgeben. Viele Tabellen in einem TRUNCATE abschneiden rufen Sie an, wenn Sie können. Es gibt eine Einschränkung, wenn Sie viele TRUNCATES verwenden von kleinen Tischen immer wieder; siehe:Postgresql-Trunkierungsgeschwindigkeit
Wenn Sie keine Indizes für Fremdschlüssel haben, DELETE s mit den Primärschlüsseln, auf die diese Fremdschlüssel verweisen, werden schrecklich langsam sein. Stellen Sie sicher, dass Sie solche Indizes erstellen, wenn Sie jemals damit rechnen, DELETE zu werden aus der/den referenzierten Tabelle(n). Indizes sind für TRUNCATE nicht erforderlich .
Erstellen Sie keine Indizes, die Sie nicht benötigen. Jeder Index hat Wartungskosten. Versuchen Sie, einen minimalen Satz von Indizes zu verwenden, und lassen Sie sie von Bitmap-Index-Scans kombinieren, anstatt zu viele riesige, teure mehrspaltige Indizes zu verwalten. Wenn Indizes erforderlich sind, versuchen Sie zuerst, die Tabelle zu füllen, und erstellen Sie dann am Ende Indizes.
Hardware
Genügend RAM zu haben, um die gesamte Datenbank aufzunehmen, ist ein großer Gewinn, wenn Sie es verwalten können.
Wenn Sie nicht über genügend RAM verfügen, ist der schnellere Speicher umso besser. Selbst eine billige SSD macht einen massiven Unterschied zu Schleuderrost. Vertrauen Sie jedoch nicht auf billige SSDs für die Produktion, sie sind oft nicht absturzsicher und könnten Ihre Daten fressen.
Lernen
Das Buch von Greg Smith, PostgreSQL 9.0 High Performance, bleibt relevant, obwohl es auf eine etwas ältere Version verweist. Es sollte eine nützliche Referenz sein.
Treten Sie der allgemeinen PostgreSQL-Mailingliste bei und folgen Sie ihr.
Lesung:
- Optimieren Ihres PostgreSQL-Servers – PostgreSQL-Wiki
- Anzahl der Datenbankverbindungen - PostgreSQL-Wiki
