PageBuffers werden nicht richtig angewendet

[hoika]

Hallo,
auf der Festplatte. Dazu gibt es ja das einstellbare Temp-Verzeichnis
in der Firebird.conf.

Ich versuche zu berechnen, wie groß ich die PageSize für einen Kunden setzen kann.

Hier ein interessanter Link
http://www.josh-hartmann.com/incompe...eveloper-woes/


Heiko

[Perlsau]

Auf der Festplatte? Das würde bei einer großen Ergebnismenge ja ewig dauern bei den Zugriffszeiten!

Wenn du ein Select-Query mit einem Order-Befehl absetzt und der eine Ergebnismenge zurückliefert, die sortiert werden muß, dann geschieht das immer im Speicher, ob das jetzt das DBMS macht oder deine Query oder dein Dataset.

Vermutlich geht's in diesem Link um irgend einen Cashe, der mit Sicherheit im Speicher vorbereitet wird, bevor er auf die Platte kommt. Aber sorry, ich hab jetzt keine Zeit, den Text in diesem Link zu lesen und zu übersetzen, stehe etwas unter Termindruck.

[hoika]

Hallo,
kein Problem.

Ich muss mir das auch erst mal genau durchlesen.
Im Moment bin ich genau so ein Developer wie beschrieben

Heiko

[p80286]

Naja externe Sortierverfahren sind ja nicht ganz neu, allerdings finden die Vergleiche immer noch im Hauptspeicher statt, und um eine möglichst hohe Performance zu erreichen sollte möglichst viel Hauptspeicher genutzt werden.

Gruß
K-H

[hoika]

Hallo,
stimmt bei FB nicht ganz.
Bei großen ResultSets wird das Ergebnis im Temp abgelegt.

Ich sollte also am besten ein bisschen RAM übrig lassen
bei meiner Berechnung der besten PageSize.


Heiko

[tsteinmaurer]

Firebird verwendet für unterschiedliche Dinge verfügbaren RAM. Page Cache, Metadaten Ache, temp. Ergebnismengen by ORDER / GROUP BY, Lock Manager etc. Page Cache, RAM für temp. Ergebnismengen und Lock Manager läßt sich konfigurieren. Abhängig von der verwendeten Firebird Architektur (SuperServer, SuperClassic, Classic) kommt dann noch die Anzahl der DB-Verbindungen als Multiplikationsfaktor hinzu.