Re: Unterschied PostgreSQL unter Windows/Unix

Bei einem DB Test unter windows und Unix (speziell FreeBSD)
habe ich leider einen unerfreulichen Unterschied feststellen müssen.

Der Test ist eine Mischung aus Insert/Select und Delete Statements mit Verknüpfungen
über mehrere Tabellen.
Die Anzahl der Datensätze wächst dabei in den Tabellen systematisch.
Zum Schluss sind in der größten Tabelle ca. 1/2 Million Einträge.

Unter FreeBSD bleibt die Zeit für eine Testblock (mit den div. Statements)
mit zunehmender Tabellengröße ungefähr gleich bzw. ein ganz leichter Anstieg
der Zeit.

Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzahl der Einträg :-(

Die statistikinfos belegen aber eine gute Nutzung der Inizes.

Kennt jemand dieses Verhalten und kann ggf. Tips geben?

Danke,

Mike

Mike Schubert <mike(dot)schubert(at)interface-projects(dot)de> schrieb:

> Bei einem DB Test unter windows und Unix (speziell FreeBSD)
> habe ich leider einen unerfreulichen Unterschied feststellen müssen.
>
> Der Test ist eine Mischung aus Insert/Select und Delete Statements mit Verknüpfungen
> über mehrere Tabellen.
> Die Anzahl der Datensätze wächst dabei in den Tabellen systematisch.
> Zum Schluss sind in der größten Tabelle ca. 1/2 Million Einträge.
>
> Unter FreeBSD bleibt die Zeit für eine Testblock (mit den div. Statements)
> mit zunehmender Tabellengröße ungefähr gleich bzw. ein ganz leichter Anstieg
> der Zeit.
>
> Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzahl der Einträg :-(
>
> Die statistikinfos belegen aber eine gute Nutzung der Inizes.
>
> Kennt jemand dieses Verhalten und kann ggf. Tips geben?

Windows ist Scheiße, nimm UNIX ;-)

Mmmh. Der Windows-Port ist sehr neu. Erwarte keine Wunder.

Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)

On Wed, Mar 30, 2005 at 05:26:05PM +0200, Kretschmer Andreas wrote:
> Mike Schubert <mike(dot)schubert(at)interface-projects(dot)de> schrieb:
>
> Windows ist Scheiße, nimm UNIX ;-)

Mhh, die Aussage hilft nicht, da neben FreeBSD/Linux/Solaris eben
auch Windows sein muss :-|

>
> Mmmh. Der Windows-Port ist sehr neu. Erwarte keine Wunder.
>

gut, ich habe noch vergessen zu erwähnen, das ein anderer Test, der jedoch
die Daten nicht so "normalisiert" - sprich etwas redundanter und damit mit
weniger Vergnüpfungen - speichert, zeigt auch unter Windows einen konstanten
Zeitverlauf.

Deshalb gehe ich davon aus, dass irgendetwas im zusammenspiel "viele (und grosse)
Tabellen + windows" etwas hakt. Ich bin mit meinem Latein am Ende und ohne
Eingrenzung der Ursache ist auch keine Beseitigung möglich :-/

Vielleicht ist ja schon jemand weiter gekommen als ich.

Trotzdem erst einmal Danke, ich hoffe noch auf Ideen :-)

MfG

Mike

Schreib am besten auf englisch an -performance oder die win32-liste.
Kreise vorher das Problem auf eine oder mehrere Querys ein. Der
Empfänger muss zum Beheben des Problems das Problem reproduzieren
können. Versuche, mit deiner Mail möglichst nahe an das Ideal
heranzukommen. Das Ideal sind hier ein paar Dateien mit allen nötigen
Daten und knappen präzisen Erklärungen, worum es geht und wo die
Ungereimtheit ist.

Markus

В Срд, 30/03/2005 в 12:39 +0200, Mike Schubert пишет:
> Bei einem DB Test unter windows und Unix (speziell FreeBSD)
> habe ich leider einen unerfreulichen Unterschied feststellen müssen.
>
> Der Test ist eine Mischung aus Insert/Select und Delete Statements mit Verknüpfungen
> über mehrere Tabellen.
> Die Anzahl der Datensätze wächst dabei in den Tabellen systematisch.
> Zum Schluss sind in der größten Tabelle ca. 1/2 Million Einträge.
>
> Unter FreeBSD bleibt die Zeit für eine Testblock (mit den div. Statements)
> mit zunehmender Tabellengröße ungefähr gleich bzw. ein ganz leichter Anstieg
> der Zeit.
>
> Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzahl der Einträg :-(
>
> Die statistikinfos belegen aber eine gute Nutzung der Inizes.
>
> Kennt jemand dieses Verhalten und kann ggf. Tips geben?
>
> Danke,
>
> Mike
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
--
Markus Bertheau ☭ <twanger(at)bluetwanger(dot)de>

> Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzahl der
> Einträg :-(
Es könnte ein Problem der Speicherverwaltung von Windows zu sein.
> Die statistikinfos belegen aber eine gute Nutzung der Inizes.
Vielleicht hilft es die statisikinfos aufzufrischen (VACUUM?).

Michael

On Thu, Mar 31, 2005 at 11:36:21AM +0200, Markus Bertheau ??? wrote:
> Schreib am besten auf englisch an -performance oder die win32-liste.
> Kreise vorher das Problem auf eine oder mehrere Querys ein. Der
> Empfänger muss zum Beheben des Problems das Problem reproduzieren
> können. Versuche, mit deiner Mail möglichst nahe an das Ideal
> heranzukommen. Das Ideal sind hier ein paar Dateien mit allen nötigen
> Daten und knappen präzisen Erklärungen, worum es geht und wo die
> Ungereimtheit ist.

Bei den einzelnen Querys fangen die Probleme an, da ich die nicht genau kenne.
Es wird beim Test ein Ontologieframework (namens Jena) genutzt.
Ich kenne nur aus dem API-Studium, dass eine Menge Insert/Select/Delete
Operationen abgesetzt werden.

Deshalb kann ich nicht mal eingrenzen, ob alle Statements die gleiche
"Verlangsamung" bekommen, oder nur ein bestimmter Teil.

Für mich ist entscheident, wieviel Zeit ich zum Speichern einer Resource
mit n Properties brauche. Beim Speichern dieser Resource mit den Properties und
den Zusammenhängen wird ide DB ganz schön beackert. Ich komme leider aus der
MSSQL Ecke, so dass ich bei PostgreSQL nicht weiss, wie ich bestimmte
Statements mit deren Ablaufzeit in der Datenbank analysieren kann.
(Kannst du ggf. einen Hinweis geben?)

Anhande der verschiedenen pg_stat* und pg_statio* Views konnte ich schon erst einmal
herauslesen, das die Indizes gut genutzt werden.

Vielen Dank für deine Antwort und deinen Hinweis auf die o.g. Listen,

Mike

--
interface projects GmbH Tel.: ++49-351-3 18 09 15
Tolkewitzer Str.49 Fax.: ++49-351-3 36 11 87
D-01277 D R E S D E N E-Mail: mike(dot)schubert(at)interface-projects(dot)de

Ein Unternehmen der interface:business-Gruppe
http://www.interface-projects.de

On Thu, Mar 31, 2005 at 01:47:02PM +0200, Michael Koenig wrote:
> > Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzahl der
> > Einträg :-(
> Es könnte ein Problem der Speicherverwaltung von Windows zu sein.

Meine Vermutungen gehen auch in Richtung unterchiedlicher resourcenverwaltung
bei Unix und Windows. Nur ist die Frage welcher Punkt ist der entscheidende
und wie kann man das Problem umgehen. (ohne das Os zu wechseln :-)

> > Die statistikinfos belegen aber eine gute Nutzung der Inizes.
> Vielleicht hilft es die statisikinfos aufzufrischen (VACUUM?).
>

Jeder Testlauf beginnt mit einer "frischen" DB.

Ich habe auch wärend des Testlaufes schon mit Vacuum hantiert, da ich vermutete,
dass evtl. viele als gelöscht markierte Entries die Geschwindigkeit beeinflussen -
aber nichts dergleichen.

Danke,

Mike
--
interface projects GmbH Tel.: ++49-351-3 18 09 15
Tolkewitzer Str.49 Fax.: ++49-351-3 36 11 87
D-01277 D R E S D E N E-Mail: mike(dot)schubert(at)interface-projects(dot)de

Ein Unternehmen der interface:business-Gruppe
http://www.interface-projects.de

В Чтв, 31/03/2005 в 13:49 +0200, Mike Schubert пишет:

> Für mich ist entscheident, wieviel Zeit ich zum Speichern einer Resource
> mit n Properties brauche. Beim Speichern dieser Resource mit den Properties und
> den Zusammenhängen wird ide DB ganz schön beackert. Ich komme leider aus der
> MSSQL Ecke, so dass ich bei PostgreSQL nicht weiss, wie ich bestimmte
> Statements mit deren Ablaufzeit in der Datenbank analysieren kann.
> (Kannst du ggf. einen Hinweis geben?)

Wenn du mit psql auf die Datenbank kommst, kannst du mit

\timing

Zeitmessung anschalten. Nach allen nach diesem Kommando abgesetzten
Queries wird die Laufzeit ausgegeben. Sehr wichtig sind auch EXPLAIN
(dieses Kommando gibt den Ausführungsplan aus) und EXPLAIN ANALYZE (Plan
+ Ausführungszeiten für die einzelnen Schritte). Insbesondere im
Vergleich zu Linux, um die Unterschiede feststellen zu können. Eine
weitere Möglichkeit ist es, in postgresql.conf anzuschalten, daß die
Statements und ihre Dauer protokolliert werden. Man kann auch nur
Statements protokollieren, die länger als eine bestimmte Zeit gedauert
haben.

Markus

--
Markus Bertheau ☭ <twanger(at)bluetwanger(dot)de>