<region_name>: collision rate (<percentage>%), <number_of> collisions, <number_of> accesses on region <region_ID>
Die Rate der Sperrkollisionen ist hoch.
In unterschiedlichen Threads laufende Tasks versuchen parallel auf einen globalen Speicherbereich zuzugreifen. Bei der dafür notwendigen Synchronisation treten gehäuft Kollisionen auf.
Eine Ausnahme hiervon sind bei liveCache-Instanzen
hohe Kollisionsraten in den Bereichen (<region_id>)
OMSVDIR und
CNSTVIEW. Diese
sind bei bestimmten Aktionen, z.B. gleichzeitigem CIF-Queue-Transfer,
normal.
Handlungsbedarf besteht bei
Kollisionsraten von mehr als 10 Prozent. Generell steigt die
Kollisionswahrscheinlichkeit mit wachsender Anzahl genutzter Prozessoren (allgemeiner
Datenbankparameter MAXCPU). Sie sollten daher prüfen, ob bei
Multiprozessorsystemen das Datenbanksystem die Anwendungsanforderungen auch
mit weniger CPUs erfüllen kann.
Treten in Multiprozessor-Zentralsystemen
(Datenbanksystem und Anwendung laufen auf dem gleichen Rechner) hohe
Kollisionsraten auf, sollten Sie überprüfen, ob der Rechner CPU-seitig
überlastet ist und die Datenbank-Threads durch andere Anwendungen blockiert
werden. In diesem Fall sollten diejenigen Datenbank-Threads, die User-Tasks
enthalten, vom Betriebssystem REAL TIME PRIORITY erhalten. Dabei muss jedoch der Wert von MAXCPU um mindestens eins
kleiner sein als die Anzahl realer CPU, um Betriebssystemblockaden zu
vermeiden.
·
Wenn die hohen Kollisionsraten in den
Bereichen DATAn,
SPLITnoder
TREEn auftreten,
dann erhöhen Sie die Werte des allgemeinen Datenbankparameters CACHE_SIZE
sowie der speziellen Datenbankparameter
_DATA_CACHE_RGNS und _TREE_RGNS.
·
Wenn die hohen Kollisionsraten in den
Bereichen TRACE oder
BUFWRTRauftreten,
dann schalten Sie den Datenbank-Trace
immer nur vorübergehend zur Problemlokalisierung ein.