it-swarm.com.de

Autodetect "random_page_cost" vs "seq_page_cost"

Ich habe diesen Artikel über die PostgreSQL-Leistung auf SSD gelesen:

https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b

Diese beiden Konfigurationen scheinen wichtig zu sein random_page_cost vs seq_page_cost

Da beide Parameter mit der jeweiligen Hardware übereinstimmen müssen, frage ich mich, ob es möglich ist, die übereinstimmenden Werte automatisch zu erkennen.

Update

Ich habe folgende Schritte im Kopf:

  1. Das Skript erstellt einige Dummy-Tabellen
  2. Skripte fügen Daten in die Tabellen ein
  3. Das Skript führt einige Abfragen durch
  4. Das Skript zeigt übereinstimmende Werte für random_page_cost und seq_page_cost
  5. Der Mensch oder ein automatisiertes System nimmt diese Werte und aktualisiert die Konfiguration. Dieser Schritt ist nicht Teil der Frage.
8
guettli

Da beide Parameter mit der jeweiligen Hardware übereinstimmen müssen, frage ich mich, ob es möglich ist, die übereinstimmenden Werte automatisch zu erkennen.

Es ist sicherlich möglich, die Parameter automatisch einzustellen, aber niemand hat einen Patch dafür eingereicht.

Sie müssen die sequentiellen und nicht sequentiellen Lesegeschwindigkeiten des Laufwerks kennen. Es gibt unzählige Möglichkeiten, dies zu erreichen, aber Sie können auch Google verwenden, da es wahrscheinlich nicht wichtig ist, das viel. Eine schnelle Google-Suche nach der sequentiellen und nicht-sequentiellen Leseleistung des Samsung SSD 840 Pro (256 GB) zeigt dies von AnandTech mit

  • Random Read 101.4/mbps
  • Sequentielles Lesen 510,7/mbps

Das ist also ungefähr ein Verhältnis von 1: 5

SET random_page_cost = 5;
SET seq_page_cost = 1;

Warnung, random_page_cost Berücksichtigt den Cache,

Der wahlfreie Zugriff auf den mechanischen Plattenspeicher ist normalerweise viel teurer als der vierfache sequentielle Zugriff. Es wird jedoch eine niedrigere Standardeinstellung verwendet (4.0), da davon ausgegangen wird, dass sich die meisten zufälligen Zugriffe auf die Festplatte, z. B. indizierte Lesevorgänge, im Cache befinden. Der Standardwert kann als Modellierung des Direktzugriffs als 40-mal langsamer als der sequentielle angesehen werden, wobei erwartet wird, dass 90% der zufälligen Lesevorgänge zwischengespeichert werden.

Wenn Sie der Meinung sind, dass eine Cache-Rate von 90% eine falsche Annahme für Ihre Arbeitslast ist, können Sie random_page_cost Erhöhen, um die tatsächlichen Kosten für zufällige Speicherlesevorgänge besser widerzuspiegeln. Wenn sich Ihre Daten wahrscheinlich vollständig im Cache befinden, z. B. wenn die Datenbank kleiner als der gesamte Serverspeicher ist, kann eine entsprechende Verringerung von random_page_cost Geeignet sein. Speicher, der im Vergleich zu sequentiell, z. Solid-State-Laufwerke könnten auch besser mit einem niedrigeren Wert für random_page_cost modelliert werden.

Ich habe gezeigt, dass mein random_page_cost 5-mal langsamer als sequentiell ist. Es ist immer noch ein Platzhalter, wie viel von random_page_cost Bereits zwischengespeichert ist. Leider sind diese Werte nicht wirklich wichtig, es sei denn, der Index-Scan und der Sequential-Scan waren so nahe beieinander, dass Sie den Sequential-Scan vernünftigerweise versehentlich auswählen konnten. Das ist selten der Fall. Es ist nicht ungewöhnlich, dass ein Index die Dinge um das Tausendfache beschleunigt.

Zum Beispiel ist mein cpu_index_Tuple_cost0.005. AFAIK, das heißt, das Scannen von 1000 Einträgen im Index ist in den Augen des Planers dasselbe wie das einmalige Gehen zum Heap, um einen Block abzurufen.

8
Evan Carroll