HILFE! Bericht mit massiven Select SUM Anweisungen läuft mehr als 3 Tage

Ich habe folgendes Problem. Wir haben ein Tool das über ODBC an die Datenbank angebunden ist und einen Bericht erzeugt. Dabei werden von ca. 1 Mio. Datensätzen plus Querverweise auf andere Tabellen Summen gebildet. Dieser Prozess dauert derzeitig etwas mehr als 3 Tage. Dabei wird immer nur ein Prozess auf dem Datenbankserver gestartet und dieser wiederum nur einem CPU Core. Die Auslastung des einen Cores liegt dabei bei 100%.
Ich weiss von einer anderen Einrichtung das dies mit den gleichen Tool und mit etwa der gleichen Anzahl an Datensätzen in weniger als 2 Stunden abgearbeitet wird. Dabei ist deren Server sogar schlechter ausgestatet als unserer.

Getestet haben wir das bisher auf SUSE Linux und Ubuntu 64bit 10.4 LTS.
Der Server hat 2 x Quad Core XEON CPU, 24 GB RAM und ein RAID 5 System mit 10 Platten.
Beim pgbench kommt unser Server auf durchschnittlich 900 tps während die andere Einrichtung gerade einmal 65 tps auf einem SUSE Linux System schafft.

Ein SMP Kernel ist natürlich installiert. Und es werden auch andere CPUs/Cores angesprochen, aber eben nicht in diesem einen Fall.
Alles andere läuft auch super schnell.

Auf das Tool das die Kalkulation auf dem DB Server durchführt haben wir keinen Einfluß. Es ist also nicht möglich mehrere Verbindungen gleichzeitig zum DB Server herzustellen.

Hat jemand eine Idee an welcher Schraube man drehen könnte um die Verarbeitungsgeschwindigkeit zu erhöhen?

Ich bin für jede Hilfe Dankbar.

Wie sieht es mit dem Anfrageplan aus?
Wie sehen die wichtigsten Konfigurationsparameter aus?
Nutzt “die andere Einrichtung” ebenfalls PostgreSQL? Gleiche Datenbankversion? Gleiches Tool, gleiche Anfrage?


Oh, und ach so: Welcome to Greenplum | Greenplum

Also das Tool ist gleiche, die Abfragen kommen aus dem Tool. Und da das Tool in der selben Version vorliegt, laufen auch bei beiden Einrichtungen die selben SQL Abfragen. Die andere Einrichtung nutzt auch Postgresql aber eine andere Postgresql Version (8.2.6). Wir haben bisher Postgresql 8.4 und 9.0 getestet. Das brachte aber keinen Unterschied. Sonnst unterscheidet sich halt noch die Linux Distro und der Kernel.
Die Konfiguration habe ich als Text Datei angehangen.

Abfrageplan?

Andreas

Also so einen Abfrageplan kann ich nicht liefern. Hier wird mit dem Tool kein Script ausgeführt. Die Abfragen sind fest im Quellcode. Und das Tool ist soweit ich weiss mit C++ geschrieben. Die einzige Möglichkeit die ich kenne so einen Abfrageplan zu erstellen ist “EXPLAIN” vor die “SELECT” Anweisung zu schreiben. DAs einzige was ich mit Sicherheit sagen kann das es sich um Select SUM() Anweisungen handelt.
Aber an den Abfragen kann es nicht liegen da beide Einrichtungen das gleiche Tool und die gleiche Datenbankstruktur haben.

Du kannst log_min_duration setzen, dann siehst Du im Log die lang laufenden Abfragen. Dann sind diese Dir bekannt. Diese raus zu kopieren und ein EXPLAIN evtl. mit ANALYSE davor zu schreiben überlasse ich Dir zur Übung :wink:

Du kannst auch mal schauen, wie groß die Tabellen sind. Vergleiche dabei auch die Anzahl der Tupel und die Anzahl der Pages dieser Tabellen auf beiden Systemen. Vielleicht läuft ja Dein AUTOVACUUM nicht. Die Tabelle pg_class ist hierbei Dein Freund.


Andreas

6 GB RAM für die Datenbank sind ggf. etwas zuviel.
Mit 128 MB work_mem schießt ihr euch bei komplizierten Anfragen ggf. selbst in den Fuß.

Habt ihr mal den Speicherverbraucht der Maschine während der Anfrage(n) beobachtet?

6 GB folgen aber der allgemeinen 25% - Regel, er hat ja 24 GB. work_mem, nun ja, depends. Aber ohne Plan sind wir halt alle a bissl planlos …

Andreas

Also ich habe mal aus dem Logfile eine Stelle herausgepickt und in eine Textdatei geschrieben. Zwei der SQL Anweisungen die länger laufen habe ich dann noch mit EXPLAIN auf den SQL Server losgelassen und das Ergebnis ebenfalls in eine Textdatei geschrieben.

Das mit der Speicherkonfiguration habe ich jetzt noch nicht näher überprüfen können. Ich denke aber das unser Problem darin liegt das alle SQL Anweisungen die von dem Tool losgelassen werden alle nur auf einem Prozess laufen (siehe top.txt).

Nun ja.

Ist schon mal krank, ein Datum in 2 (oder mehr) INT-Spalten zu zertrümmern. Mit einem DATE hätte man da mehr erreicht. Und dann sehe ich da nur einen Seq-Scan. Gar keine Indexe? Wieviel % der Tabelle erfüllen die Bedingung der WHERE - Bedingunen?

Andreas