This article refers to legacy products, components or features. Therefore, the content in this article is offered "as is" and will no longer be updated. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.
When running in a high load environment with large numbers of worklist retrievals (mostly in a clustered environment), the K2 database server may utilize 100% of the CPU capacity. This may result in worklist timeouts.
If there are a large amount of worklist items, the Microsoft SQL server’s CPU(s) might run at 100% when opening a worklist. This is due to a default behavior of MSSQL that takes one SQL query and executes it over all available CPU’s to try and execute it faster. Therefore, while executing one large query, no one else can connect to the worklist because MSSQL is using all the CPU capacity.
In order to manage this behavior a setting has been added to the K2Server.setup file. The new setting is called 'MAXDOP' (MAXimum Degree Of Parallelism) and it allows an administrator to specify how many CPU’s to use for a single SQL query. This setting is however only applicable to the worklist. If the MAXDOP setting is set to '0' (default), then the MSSQL server continues using the default behavior (where MSSQL determines how many CPU’s to use), but if the MAXDOP value is set it to 1, for example, it will force MSSQL to only use one CPU to execute a SQL query.
For more information on the Microsoft SQL MAXDOP option read the following links:
The K2 database server will utilize 100% of the CPU capacity and a worklist timeout may occur.
This Hotfix is contained within the latest K2 Update.
Install the update package and increase the value of the <SqlMaxDop Worklist="0" /> setting in the K2Server.setup file to resolve the error.
Setting <SqlMaxDop Worklist="1" /> will limit the MSSQL server to executing a single SQL query on a single CPU. Setting <SqlMaxDop Worklist="2" /> will limit the MSSQL server to executing a single SQL query on two CPUs, and so on.