Agent Parameters

[ Team LiB ]

Agent Parameters DB2 uses a client-server based processing model. Clients or applications use agents to accomplish work within the database. DB2 uses several types of agents as follows. Coordinating Agents Coordinating agents are created for each application and manage work on behalf of applications. Coordinating agents also distribute work to subagents in a database with intra-partition parallelism enabled. The DBM CFG parameter MAX_COORDAGENTS is used to define the number of coordinating agents available to process application requests. If a coordinating agent is not available for an application, the requesting application will receive a negative SQL code. You should set MAX_COORDAGENTS such that this situation does not occur. The default for MAX_COORDAGENTS is the setting of the MAXAGENTS DBM CFG parameter. This setting is a good starting point. In an ESE environment without partitioning enabled or intra_parallel set to YES, MAX_COORDAGENTS must equal MAXAGENTS. MAXAGENTS The MAXAGENTS DBM CFG parameter specifies the maximum number of database manager agents, whether coordinating or subagents available at any given time to accept application requests. In memory constrained environments, MAXAGENTS can be set low so as to limit the total memory usage of the database manager as each additional agent requires additional memory. If you use this to limit resources, remember it is only a temporary solution. You will need to reduce resource consumption or acquire additional capacity to support your business requirements. MAXCAGENTS MAXCAGENTS defines the Maximum Number of Concurrent Agents that can be executing in the database manager. Before an agent can do work for an application it must obtain a token from the database manager. If a token is not available, the agent will wait. MAXCAGENTS controls the number of tokens available. The default is that MAXCAGENTS is equal to MAX_COORDAGENTS. Start with the default and adjust through benchmark testing. Generally, you don't want agents waiting for a token. You can monitor this with a DBM snapshot. If agents waiting for tokens occurs frequently then MAXCAGENTS and other related agent parameters should be increased until agents waiting for tokens is 0, or occurs very infrequently. MAXAPPLS MAXAPPLS defines the maximum number of concurrent applications that can be connected to the database. If MAXAPPLS is reached, an error will be returned to any application attempting to connect to the database and a connection will not be established. In v8, MAXAPPLS can be set to automatic which will allow any number of connected applications. If resources are not a concern, set MAXAPPLS to automatic. If resources are constrained (due to CPU or memory constraints), then set MAXAPPLS equal to or greater than the sum of the connected applications, plus the number of these same applications that may be concurrently completing a two-phase commit or rollback; plus the sum of the anticipated number of in-doubt transactions that might occur at any time. MAXAPPLS is also governed by MAXAGENTS. An application can only connect to the database if there is an available connection (MAXAPPLS) as well as an available agent (MAXAGENTS). Additionally, no new applications (coordinating agents) can be started if MAX_COORDAGENTS has been reached.

[ Team LiB ]