[Allegro] a99 : Entschleunigung wieder entkräftet

[Thomas Berger]

Lieber Herr Eversberg,

> liegt ein a99, in dem wir die vielbeklagte Entschleunigung wieder
> rückgängig gemacht haben. Sie ergab sich aus dem Einsatz eines anderen
> Unterprogramms für den Indexzugriff, und zwar genauer auf den jeweils
> nächsten Eintrag. Das passiert in einer Schleife viele Male
> hintereinander, wenn ein Indexausschnitt präpariert wird. Das
> "andere Unterprogramm" macht dabei jedesmal wieder einen kompletten
> Suchzugriff, beginnend bei der Wurzel des B*-Baums (das ist die interne
> logische Struktur des Index), und das sind viel mehr Aktionen als
> beim älteren Unterprogramm, das im Index an der gerade vorher besuchten
> Stelle weitermacht, als sei inzwischen nichts geschenen. Ist ja auch
> meistens nicht, aber in Streßsituationen wie z.B. globalen Ersetzungen
> und hochvolumigen update-Aktionen kann's passieren, daß an genau der
> Stelle nach dem vorigen Zugriff (Millisekunden vorher) was eingeschoben
> oder der Block an der Stelle geteilt wurde - das führt dann zum Abbruch
> der Anzeige. (Nicht jedoch zu irgendwelchen Schäden, es sind ja nur
> Lesezugriffe! Irritierend, aber ungefährlich.)

Sie hatten den Code dazu m.W. nie veroeffentlicht (ist allegro nicht
eigentlich inzwischen Open Source?), daher kann ich nur spekulieren:

* Kann (ich vermute: Zugriff auf den naechsten Schluessel liefert ein
  unerwartetes Ergebnis) nicht erkannt werden, dass *Bedarf* fuer
  einen Re-Scan besteht (der dann normalerweise unterbleiben kann)?
  Bzw. (ich spekuliere) kann nicht einfach die gesamte Kachel des
  Index (2kB?) an der Stelle eingelesen werden und die bedient dann
  ggfls. mehrere sequentielle Anfrage nach Schluesseln?


* Anwender haben mir Hinweise darauf gegeben, dass insbesondere der
  Wechsel des Registers problematisch ist und zu Abbruechen vor oder
  bei der ersten gezeigten Zeile im Index fuehrt.


> Wir könnten letzteres versuchsweise auch dadurch unterbinden, daß wir
> vor dem Aufbau eines Registerabschnitts für die Anzeige eine Sperrung
> der TBL ausführen lassen! Dann müßte aber a99 u.U. lange warten, bis
> es anfangen kann mit der Indexanzeige, und die anderen Prozesse
> (glob. Ersetzung oder Update) würden oft unterbrochen, weil ein Satz
> erst gepeichert werden könnte, wenn gerade keiner im Index blättert.

Nach meinem rudimentaeren Verstaendnis wird beim Schreiben in den
Index (waehrenddessen ist die .TBL gesperrt, d.h. u.a. niemand anderes
kann derweil in den Index schreiben) ein exklusives Range-Lock
auf *1-Byte-Repraesentanten* fuer die betroffenen Kacheln gesetzt:
Prozesse, die den entsprechenden Bereich lesen, setzen allerdings
kein nicht-exklusives Lock, sondern lesen einfach drauflos: Das
sind dann gerade die Effekte, an denen wir aktuell herumlaborieren.
(Ich unterstelle: Als Kollateralschaden dieser Repraesentanten-
Methode sind dafuer einzelne Bytes in zentralen Datenstrukturen in
den ersten x Kilo-Byte der Indexdatei oft nicht zugreifbar und fuehren
zu Fehlern bei den auslesenden Programmen.

Sie koennten ausprobieren, die fraglichen Kacheln direkt zu
locken (Leseversuche auf die jeweilige Kachel fuehren dann
zu drastischen Fehlern bzw. evtl. laesst sich dem Aufruf mitteilen,
dass er 100ms Zeit fuer den Zugriff hat und ein Lock abwarten
kann), und/oder die Lesezugriffe so umzustellen, dass sie sich
am Range-Locking der Schreibzugriffe beteiligen: Das ist zwar
immer noch eine bremsende Aktion, aber viel spezifischer und
auch leichtgewichtiger als eine Datenbanksperre (Range-Lock
auf .TBL-Datei-Byte, Sperrvermerk in die .TBL-Datei schreiben,
Range-Lock aufheben, Operation, Range-Lock auf .TBL-Datei-Byte,
Entsperrvermerk in die .TBL-Datei schreiben, Range-Lock aufheben


> Wie gesagt, das ist jetzt ein andersartiger Lösungsansatz, noch nie
> ausprobiert und offenkundig ebenfalls mit Nachteilen behaftet.
> (Beim Suchzugriff ist es anders als bei der Indexanzeige: da wird
> der jeweilige Indexvbereich, in dem gesucht wird, kurzzeitig für
> Schreibzuzgriffe gesperrt, aber das läßt sich für den Indexzugriff
> nicht in derselben Weise lösen. Bei der Ergebnismengenbildung treten
> daher zwar manchmal Langsamkeiten auf, aber keine Abbrüche.)

Ist das Index-Zeigen wirklich so verschieden vom Find-Zugriff
in den Faellen, wo Trunkierung eingestellt ist? Oder ein acon-
qrix-Kommando mit eingestellter Restriktion?

In der allgemeinen Situation sehe ich, dass erst nach dem
erfolgreichen Einsammeln der 25. Zeile (oder dem Erreichen des
Index-Ende) wirklich klar ist, wieviele Indexeintraege tatsaechlich
gelesen werden mussten und es daher nicht moeglich ist, alles
eventuell auszulesende prophylaktisch zu sperren (ausser man
versetzt die Datenbank effektiv in einen Einzelplatzbetrieb).
Aber in einer Situation, wo selbst im Normalfall durchaus
"viele" Schluessel auf einen Rutsch zu lesen sind, sollte doch
eine Optimierung moeglich sein?

viele Gruesse
Thomas Berger