<region_name>: collision rate (<percentage>%), <number_of> collisions, <number_of> accesses on region <region_ID>
The rate of lock collisions is high.
Tasks that run in different threads are attempting to access a global storage area in parallel. The synchronization that is necessary for this often leads to an increased collision rate.
One exception to this in liveCache instances is high collision rates in the areas ( <region_id>) OMSVDIR and CNSTVIEW. This is normal for certain actions, such as a simultaneous CIF queue transfer.
You need to act if the collision rate rises above 10%. Generally, the risk of collisions rises with the number of processors used (general database parameter MAXCPU). In multiprocessor systems, you should therefore check whether the database system can fulfill the needs of the applications with fewer CPUs.
If high collision rates occur in multiprocessor central systems (database system and application run on the same computer), check whether the computer’s CPU is overloaded, and whether the database threads are blocked by other applications. In this case, the database threads that contain user tasks should receive REAL TIME PRIORITY from the operating system. However, at the same time, the value of MAXCPU must be at least one lower than the number of real CPUs, to avoid operating system blocks.
If the high collision rates occur in the areas DATAn, SPLITn or TREEn, then increase the values of both the general database parameter CACHE_SIZE and the special database parameters _DATA_CACHE_RGNS and _TREE_RGNS.
If the high collision rates occur in the regions TRACE or BUFWRTR, then activate the database trace temporarily for troubleshooting only.