postgresql für große Mengen von RAM stimmen

Ich habe zwei identische Server (in Bezug auf die Hardware), beide sind Standardinstallationen von Windows Server 2008 R2 mit minimal installierter Software (im Grunde genommen mein Code und benötigtes Material 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 überwältigend. Es ist so schlecht für Postgresql, dass ich meine anfängliche Rede "Verwenden wir Postgresql, anstatt die SQL-Serverlizenz zu bezahlen" an meinen Chef bedauere. Wir sprechen von Unterschieden zwischen 30 Sekunden und 15 Minuten für denselben Befehl, und es ist nicht nur dieser eine Befehl, sondern jede Abfrage oder jeder Befehl, den ich darauf ausführe. 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, wohingegen Postgresl nichts verwendet, definitiv weniger als ein Gig, obwohl ich es nicht wirklich im Detail herausgefunden habe.

Wie bekomme ich postgresql, um mehr als 20 GB RAM zu verwenden? Diese Server wurden speziell für diese Datenbank erstellt, sodass jeder RAM, der nicht von der Datenbank und den unterstützenden Prozessen verwendet wird, meiner Meinung nach verschwendet wird.

Es gibt viele optimierbare Konstanten, die über initialisiert werden postgres.conf. 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 kann
• shared_buffers Die Menge an Speicher, die für den Pufferspeicher reserviert ist.
• effective_cache_size die Menge an Speicher, die von den LRU-Puffern des Betriebssystems verwendet werden soll.
• random_page_cost : eine Schätzung für die relativen Kosten von Festplattensuchen.

max_connectionsSollte nicht höher als erforderlich eingestellt werden, kosten Verbindungen Ressourcen, auch wenn sie nicht in Betrieb sind. In den meisten Fällen würde eine Verbindung mehr Zeit damit verbringen, drinnen als draußen zu warten. (zum Preis der Nebenläufigkeit) Eine schöne Faustregel lautet "Anzahl der Spindeln + Anzahl der Prozessoren + X".

work_memist knifflig: ist kann auf jede Unterabfrage angewendet werden, daher kann eine Abfrage mit 5 HASHJOINS5 * kosten work_mem. Und im schlimmsten Fall sollten Sie auch daran denken, dass mehrere Sitzungen diese Menge verbrauchen (wieder ein Grund, um max_connectionsniedrig zu bleiben ).

shared_buffersist (meiner Meinung nach) überbewertet. Normalerweise wird empfohlen, etwa 1/4 ... 1/2 des gesamten verfügbaren "freien" Speichers einzustellen, aber ich neige dazu, ihn niedrig zu halten und auf effective_cache_sizeden gesamten verfügbaren "freien" Speicher einzustellen .

random_page_costsind die Kosten für ein Suchen + Lesen auf der Festplatte. Er ist relativ zu dem sequential_disk_costWert, der 1 ist. Der Standardwert (4) für random_page_costist für moderne Computer und Netzwerkspeicher zu hoch eingestellt. Normalerweise kann er auf 2 bis 1.x gesenkt werden. Bei SSDs sollte sogar 1.0 eingestellt werden, da das Suchen auf SSDs fast kostenlos ist.

Erwägen Sie die Verwendung von pgtune , um die PostgreSQL-Konfiguration zu optimieren . Aus PgFoundry:

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

Die Standardkonfiguration von PostgreSQL ist sehr konservativ und dieses Tool soll genau in 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 PostgreSQL-Konfiguration und der manuellen Optimierung.

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

• Sie stellen für jede Abfrage, die Sie ausführen, 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 auszuführen select version()? Sollte sofort sein (0,16ms auf meiner Workstation).

Wenn JEDE Abfrage so viel langsamer ist, stimmt etwas schrecklich nicht mit dem Server oder etwas anderem. Nach meiner Erfahrung hat jede Datenbank ein paar Dinge, die sie besser kann als die andere, aber leistungsmäßig ist pgsql leicht im selben Bereich wie mssql server.

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 ...;

Poste die Ausgabe auf http://explain.depesz.com/ und poste den Link hier.