In general, a database instance uses several user kernel threads (see Threads and Tasks of a Database Instance). To distribute tasks optimally to the user kernel threads of the database instance, the database system performs load balancing. This ensures that on computers with several processors, resources are distributed in a better way, and shorter response times for the individual users can be achieved.
Load balancing is available from software version 7.4.03.
The operating system has no influence over how the database system distributes tasks to the available user kernel threads. Therefore, it cannot intervene, for example, if a user kernel thread uses a processor at 100% capacity, but the computer’s three other processors are not used at all.
Tasks behave generally cooperatively in a user kernel thread. They themselves decide when they are suspended and have the next waiting task processed in the same user kernel thread (see Task Switch). This behavior can lead to a single task blocking all other tasks in the same user kernel thread.
In load balancing, the timer (special thread) distributes the tasks to the individual user kernel threads. The timer asks at regular instances how long the individual tasks have been waiting in the user kernel threads (see Overview of the Task Statuses) and adds up these wait times for each user kernel thread.
If the total of the wait times in one user kernel thread is much greater than in another, then the timer has the task that has been waiting the longest in the first user kernel thread moved to the second user kernel thread.
To activate load balancing, set the LOAD_BALANCING_CHK special database parameter to a value greater than null.
See
· Database Manager GUI, Displaying and Changing Database Parameters
· Database Manager GUI, Changing the Value of a Database Parameter
User kernel thread UKT1 contains tasks T1, T2, T3, UKT2 contains task T4. T1 is in a long loop, whereas T2 and T3 are waiting.
The total of the wait times in UKT1 is 210 ms, in UKT 2 it is only 10 ms. This is why T2, which has been waiting the longest in UKT1, is moved to UKT2.