The operating system has no influence over how the database system distributes the tasks of a database system to the available user kernel threads. Therefore, it cannot intervene, for example, if a user kernel thread uses one processor at 100% capacity while the computer’s other three processors are not being used at all.
Within a user kernel thread, tasks behave cooperatively, that is, they decide when to suspend themselves and let the next waiting task take over (see Task Switching). This behavior can lead to a single task blocking all other tasks in the same user kernel thread.
To distribute tasks optimally to the user kernel threads, the database system performs internal load balancing. In so doing, the database system ensures better distribution of resources - in particular on computers with multiple processors - and shorter response times for individual users.
To configure the maximum number of processors that are used in parallel, use the MAXCPU general database parameter.
In load balancing, the timer (special thread) distributes the tasks to the individual user kernel threads. At regular intervals, the timer analyzes how long the individual tasks have been waiting in the user kernel threads (see Overview of the Task States) 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.
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.