it-swarm-eu.dev

Tuning postgresql für große Mengen an RAM

Ich habe zwei identische Server (in Bezug auf Hardware), beide sind Standardinstallationen von Windows Server 2008 R2, mit minimaler installierter Software (im Grunde mein Code und erforderliche Dinge wie JVM usw.).

Auf dem einen Server verwende ich SQL Server 2005, auf dem zweiten Server Postgresql 9.1. Der Leistungsunterschied zwischen diesen beiden Servern ist erstaunlich. Auf postgresql ist es so schlimm, dass ich meine anfängliche Rede "Lasst uns postgresql verwenden, anstatt für die SQL-Serverlizenz zu bezahlen" an meinen Chef bedauere. Wir sprechen von Unterschieden von 30 Sekunden gegenüber 15 Minuten für denselben Befehl, und es ist nicht nur dieser eine Befehl, es ist jede Abfrage oder jeder Befehl, den ich darauf wirfe. Beide haben so ziemlich die gleichen Daten (Datensätze wurden in unterschiedlicher Reihenfolge eingefügt), und beide Datenbanken haben genau die gleiche Struktur/Indizes usw.

Aber ich hoffe, es ist nur eine Frage der Leistungsoptimierung. Die Sache ist, SQL Server verwendet so ziemlich alle 32 GB RAM auf dem Server, während Postgresl nichts verwendet, definitiv weniger als ein Gig, obwohl ich es nicht wirklich im Detail herausgefunden habe.

Wie kann ich postgresql dazu bringen, mehr als 20 GB RAM zu verwenden? Diese Server wurden speziell für dieses Datenbankmaterial entwickelt, sodass meiner Meinung nach jeder RAM, der nicht von der Datenbank und den unterstützenden Prozessen verwendet wird, verschwendet wird.

29
user85116

Es gibt viele optimierbare Konstanten, die über postgres.conf Initialisiert werden. Die wichtigsten sind:

  • max_connections: Die Anzahl der gleichzeitigen Sitzungen
  • work_mem: Die maximale Speichermenge, die für Zwischenergebnisse wie Hash-Tabellen und zum Sortieren verwendet werden soll
  • shared_buffers Die Größe des Speichers, der dem 'angehefteten' Pufferplatz zugewiesen ist.
  • effective_cache_size Die Speichermenge, die von den LRU-Puffern des Betriebssystems verwendet wird.
  • random_page_cost: Eine Schätzung der relativen Kosten für Festplatten-Suchvorgänge.

max_connections Sollte nicht höher als erforderlich eingestellt werden. Verbindungen kosten Ressourcen auch im Leerlauf. In den meisten Fällen würde eine Verbindung mehr Zeit damit verbringen, drinnen zu warten als draußen. (zum Preis der Parallelität) Eine nette Faustregel lautet "Anzahl der Spindeln + Anzahl der Prozessoren + X".

work_mem Ist schwierig: Es kann auf jede Unterabfrage angewendet werden, sodass eine Abfrage mit 5 HASHJOINS 5 * work_mem Kostet. Und für Worst-Case-Szenarien sollten Sie auch an mehrere Sitzungen denken, die diesen Betrag verbrauchen (wiederum ein Grund, max_connections Niedrig zu halten).

shared_buffers Ist (IMHO) überbewertet. Normalerweise wird empfohlen, den Wert auf etwa 1/4 ... 1/2 des gesamten verfügbaren "freien" Speichers einzustellen, aber ich neige dazu, ihn niedrig zu halten und effective_cache_size Auf den gesamten verfügbaren "freien" Speicher einzustellen.

random_page_cost Sind die Kosten für ein Suchen + Lesen auf der Festplatte. Es ist relativ zu sequential_disk_cost, Das 1 ist. Die Standardeinstellung (4) für random_page_cost Ist für moderne Maschinen und Netzwerkspeicher zu hoch eingestellt. Normalerweise kann sie auf 2 bis 1 gesenkt werden. x. Für SSD-Festplatten sollten Sie sogar 1.0 festlegen, da die Suche auf SSDs fast kostenlos ist.

41
wildplasser

Verwenden Sie pgtune , um die PostgreSQL-Konfiguration zu optimieren. Von PgFoundry:

pgtune verwendet die wimpy-Standarddatei postgresql.conf und erweitert den Datenbankserver so, dass er genauso leistungsfähig ist wie die Hardware, auf der er bereitgestellt wird

Die Standardkonfiguration von PostgreSQL ist sehr konservativ und dieses Tool soll in genau dieser Situation helfen. Die Dokumentation ist leicht zu lesen und die Verwendung des Tools ist ziemlich einfach.

Beachten Sie, dass Sie die genauen Vorschläge von pgtune nicht verwenden müssen. Wenn Sie mit den Einstellungen spielen und die daraus resultierenden Änderungen an der conf-Datei beobachten, erhalten Sie ein besseres Verständnis der Konfiguration von PostgreSQL und der manuellen Optimierung.

20
Paul Bellora

Wenn jede Abfrage oder jeder Befehl langsam ausgeführt wird, vermute ich Folgendes:

  • sie stellen für jede von Ihnen ausgeführte Abfrage eine Verbindung zur Datenbank her.
  • sie haben eine Art Authentifizierungsmethode konfiguriert, die nicht funktioniert und Ihre Abfragen anhält, bis diese bestimmte Authentifizierungsmethode abgelaufen ist.

Können Sie uns bitte mitteilen, wie lange es dauert, eine Abfrage wie select version() auszuführen? Sollte sofort sein (0,16ms auf meiner Workstation).

3
Tometzky

Wenn JEDE Abfrage so viel langsamer ist, stimmt etwas furchtbar nicht mit dem Server oder so. Nach meiner Erfahrung hat jede Datenbank ein paar Dinge, die sie besser kann als die andere, aber in Bezug auf die Leistung befindet sich pgsql leicht im selben Bereich wie der mssql-Server.

Also, auf welchem ​​Betriebssystem läuft pgsql? Welche Hardware? Welche Einstellungen haben Sie bereits geändert? Wie groß ist Ihr Datensatz? Was ist ein Beispiel für eine schlechte Abfrage und die Ausgabe von EXPLAIN-Analyse? (Führen Sie Ihre Abfrage folgendermaßen aus:

erklären analysieren auswählen ... Rest der Abfrage hier ...;

Veröffentlichen Sie die Ausgabe unter http://explain.depesz.com/ und veröffentlichen Sie den Link hier.

2
Scott Marlowe