Datenbank-Optimierungen/fein-tuning

Datenbank-Optimierungen/fein-tuning

Datenbank-Optimierungen/fein-tuning : Mehreren tausend Tipps, um Ihr Leben einfacher machen.

Optimieren Sie Ihre Datenbankparameter, um das Maximum daraus extrahieren!

Hallo

Dies sind nur wenige von meiner Erfahrung während ich eine Suchmaschine und Optmising die Postgresql-Datenbank in Richtung sonic-Geschwindigkeiten Aufbau war!

Unsere Konfiguration für den Postgresql-Server war:
RedHat 7.2
PIV 2,00 Ghz System
1024MB RAM

Eines der ersten Dinge, die ich bemerkte nach dem Einschalten des Servlet-Programms, das war zwar fast genauso schnell ab dem vorherigen MySQL Abfragen zurückgegeben wurden basiertes System, die Belastung des Servers war viel höher. Dann begann ich zu gehen in die Tiefe Details der Dinge. Ich hatte MySQL vorher durch starke Erhöhung Cache und Puffer-Größen und mehr Ram auf das Problem werfen optimiert. Die einzelne größte Sache, die man hat zu tun, vor dem Ausführen von Postgresql, ist genug Platz für gemeinsam verwendete Puffer bereitstellen. Aber dann,
Wie viel ist genug?
Es ist eine heftige Debatte darauf, zwischen Menschen, die sagen, dass logisch das gesamte RAM gegenüber jenen gewidmet, die sagen sein könnte, dass werfen mehr RAM, nachdem eine bestimmte Grenze keine Verwendung hat. Mehr gemeinsame Puffercache Sie haben, desto größer der Anteil der Ihre Datenbank, daß weder Ursachen (lesen) noch Speicher vom Puffercache OS kopieren. Aber Sie werden insgesamt eine kleinere Anzahl der Blöcke Zwischenspeichern, weil Sie ihnen doppelte Pufferung werden. Wenn Sie einen Block aus dem OS-Puffer auf den freigegebenen Speicher kopieren, existiert die Kopie noch in der OS-Puffer. Dieser Block wird also jetzt doppelt gepuffert. Ein einzelnes Plattenzugriffe ist weit teurer als hunderte von Kopien zwischen den Puffercache OS und Postgres' shared Memory. Betrachten Sie auch all die anderen Dinge, du das an der Maschine machst--nur Kleinigkeiten, wie Cron und so. All, die hat einen Speicher. Daher ist es gefährlich, nicht das OS ein gutes Stück Speicher verwalten lassen.
Es kommt, dass diese beiden gegensätzlichen Faktoren aufgetragen werden könnten und etwas wie eine Linie machen. Wo sie überquerten wäre der ideale Punkt.

Außerdem optimiert ich auch SQL-Abfragen, die maßgeschneidert für meine Zwecke. Ein großer Nachteil in PostgreSQL liegt bei der Durchführung der Evaluierung von Abfragen, die mit 'Rein' und 'EXISTS'. Angenommen:
Abfrage 1. Wählen Sie * aus 'DB1' WHERE ID IN ((SELECT Id FROM db2 wo Wort = 'was')) LIMIT 20;
Abfrage 2. Wählen Sie * aus db1 wo ID IN(1234,2345,1242,1256,1245,1567,2222,22,345,234,567,456,35,56);

(ID ist der Primärschlüssel)

Die spätere Abfrage wird über den Index auf ID während des ehemaligen verläuft in einen sequentiellen Scan gescannt. Ich denke, Dies nennt man 'Pilotenfehler' worin die Datenbank die Unterabfrage für jede Zeile in der äußeren Abfrage ausgeführt wird. Stattdessen verwenden wir explizite JOINS (wie unten) konnte dann wir die Datenbank verwenden einen Index-Scan zwingen.
Letzte Frage:
Wählen Sie * aus db1, db2, db2-b
wo Id = a.id und a.word='word1 '
und Id = b.id und b.word='word2 '
etc.

Hinweis: Sie könnten auch in einen sequentiellen Scan, statt einer erwarteten Indexscan ausgeführt, wenn die Anzahl der Tupel gescannt werden mehr als 30-40 % gesamt Tupel in der Tabelle sind. Dies kann jedoch durch Ändern der Gewichte, Random_page_cost, Cpu_tuple_cost, Cpu_index_cost und Cpu_operator_cost vom Optimierer verwendet für die Herstellung dieser Vorgangsweise zugewiesen variiert werden.

Ich habe auch beschlossen, mehr RAM für den Zweck zu werfen. Ich zugeteilt 64MB RAM, in Richtung der gemeinsamen Pufferspeicher. Die Datei /var/lib/pgsql/data/postgresql.conf enthält die Einstellungen für den Datenbankserver. PostgreSQL verwendet freigegebenen Systemspeicher als Puffer. Auf einem Linux-System können Sie sehen, wie viel Speicher von Ihrem System reserviert wurde, durch Ausführen des Befehls:
Katze /proc/sys/kernel/shmmax
Und shared-Memory-Einsatz auf dem System anzuzeigen:
IPCs
Das Ergebnis wird in Byte sein. RedHat 7.2 reserviert standardmäßig 32MB shared-Memory, die möglicherweise nicht genug für Postgresql. Ich erhöht diese Begrenzung auf 64MB auf diese Weise den Befehl:
Echo 67108864 > /proc/sys/kernel/shmmax

Diese Zeile in Ihre Postgresql-Startdatei oder durch Bearbeiten der Datei /etc/rc.d/rc.local für eine dauerhafte Einstellung platziert werden müssen. Dann in unsere postgresql.conf ich Shared_buffers auf 8192.I legen auch unsere Sort_mem auf 16384 (16Megs für eine Art Speicherbereich). Da das Verbindungs-pooling in Kraft war, festgelegt ich Max_connections auf 50.
Und Fsync wurde auch auf falsefestgelegt.

Shared_buffers = 8192
Sort_mem = 16384
Max_connections = 50
Fsync = False

Eine Anhängevorrichtung fand ich anfangs war, dass das System aufbauen und Beenden einer Verbindungs mit jeder Anforderung. Dies war unerträglich, also fing ich an, das Verbindungs-pooling Features von Harz (als https://caucho.com) zu verwenden.

-----
Varun

Danksagung: Curt, Bruce, Andrew et alle zum Löschen meine Zweifel!