[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-adabas
Subject:    Re: [suse-adabas] Optimierung Kernel Parameter
From:       Joerg Bruehe <joerg () sql ! de>
Date:       2001-08-27 11:14:14
[Download RAW message or body]

Hallo in die Runde 
(und nachtraeglich allen eine schoene Urlaubszeit)!

Christof Lehmann wrote:
> 
> Hallo Michael,
> 
> > [...]
> > Wir haben wenig schreibende Zugriffe, dafür aber sehr oft einen Zugriff
> > auf Tabellen mit mehreren 100.000 Datensätzen, wobei oft kein Indexzugriff
> > stattfindet.
> Irgendwie sollte man die Datenbank dazubringen, einen Indexzugriff
> vorzunehmen.
> Wenn keine Indizes vorhanden sind, dann entsprechende Anlegen. Wenn
> vorhanden, aber nicht genutzt, dann gibt es zwei Möglichkeiten. Wenn der
> Optimierer zu der Erkenntnis kommt, daß bei der Suche mehr als 15%(?)
> gefunden werden würde, verwendet er den Index nicht. 

Richtig - und das ist eine bewusste Design-Entscheidung.

> Das kann an
> fehlerhaften Daten in der Statistik liegen (update statistics tablename)
> oder der Inhalt in der indizierten Tabelle ist nicht gleichmäßig
> verteilt.

Missverstaendlich formuliert: Auch bei aktuellen Statistik-Werten 
greift weiterhin die 15%-Regel. 
In der Formulierung "Bei fehlerhaften Statistik-Werten steigt das
Risiko, 
dass ein sinnvoller Index nicht benutzt wird" ein wichtiger Hinweis.

Ganz grundsaetzlich ist die gewaehlte Strategie abhaengig von 
1. Kommando (fuehrende Index-Felder eindeutig vorgegeben?, ...), 
2. Schema (Tabellen und Indexe), 
3. Daten (Index-Selektivitaet, 15%-Regel). 
Kernel-Parameter spielen hier keine Rolle.


> > Der Hauptspeicher hat 1 GB.
> > DataCacheHits ~ 100% 

Gut.

> > ConverterCacheHits 70-80%

_Sehr_ schlecht. 
Unbedingt den Converter-Cache vergroessern, um 99% zu erreichen. 
(Ob 100% moeglich sind oder wegen der "Cache Misses" beim Anlaufen 
nicht erreichbar, kann ich nicht sicher sagen.)

> Sucht Ihr immer nach den gleichen Datensätzen?
> Bei beiden Werten sind Beträge über 90 oder noch besser über 95
> sinnvoll.

Ganz ausdruecklich: Fuer den Converter-Cache waere 95% immer noch 
schlecht. Da jede Converter-Page viele Daten-Pages adressiert 
(ca. 170), ist jeder "Miss" im Converter-Cache potentiell sehr 
teuer. Erst wenn dieser Cache gross genug ist (99% Hit-Rate), 
werden die anderen (performance-maessig) interessant.

> Da Euer Rechner 1GB Hauptspeicher hat, kannst Du die Werte für
> DATA_CACHE_PAGES und
> CONV_CACHE_PAGES höherstellen. An Deiner Stelle würde ich mit den
> CONV_CACHE_PAGES beginnen, so daß Du nach mehreren Anfragen (möglichst
> ein guter Durchschnitt durch alle Fragen) einen Wert über 90 erreichst.
                                                            ^^ 
Siehe oben - 99%.

Die naechste Stufe ist dann _nicht_ der Daten-Cache, sondern die 
Strategie - selbst wenn die Pages im Cache stehen, ist ein Scan 
nicht so gut wie ein Index-Zugriff. 
Wenn bei dieser Analyse ein unguenstiges Schema entdeckt wird 
(oder schlechter SQL-Code), ist das zu verbessern.

Erst danach kommt der Daten-Cache an die Reihe. 
(Durch bessere Strategie kann die Anzahl der benutzten Daten-Pages 
so reduziert worden sein, dass auch ein kleinerer Cache ausreicht.)


> > [...]
> > MAXDATAPAGES     600000
> > MAXCPU          1
> > DATA_CACHE_PAGES       2000
> > PROC_DATA_PAGES        260
> > PROC_CODE_PAGES          1
> > TEMP_CACHE_PAGES         30
> > CATALOG_CACHE_PAGS       1616
> > CONV_CACHE_PAGES        400

Auf mindestens 1000 erhoehen, dann Stop-Start der DB (die Parameter 
werden nur beim Start ausgewertet), dann bei gleicher Anwendungs- 
Last neu messen. 
Solange die 99% nicht erreicht werden, diese Schritte wiederholen 
(bis maximal 4415, das laesst sich aus MAXDATAPAGES = 600000 
berechnen).


Gruss und Erfolg, 
Joerg Bruehe

-- 
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
     (speaking only for himself)
mailto: joerg@sql.de

[prev in list] [next in list] [prev in thread] [next in thread]