DB2 servers must facilitate communication between the database manager and client and local applications. UNIX-based environments use an architecture based on processes. For example, the DB2 communications listeners are created as processes. Intel operating systems such as OS/2 and Windows NT use an architecture based on threads to maximize performance. For example, the DB2 communications listeners are created as threads within the DB2 server's system controller process. For each database being accessed, various processes/threads are started to deal with the various database tasks (for example, prefetching, communication, and logging).
One of the most crucial processes/threads are those of database agents, which facilitate the operations of applications with databases.
A logical agent represents a connected application to the database manager. The logical agent has all the information and control blocks required by an application. The maximum number of logical agents is contolled by the max_logicagents database manager configuration parameter. Since each application will have one logical agent, this parameter controls the maximum number of applications that can be connected to the instance.
A worker agent carries out application requests but has no permanent attachment to any particular application. The worker agent has all the information and control blocks required to complete actions within the database manager that were requested by the application.
There are four types of worker agents: active coordinator agents, subagents, inactive agents, and idle agents.
The idle agent is the simplest form of worker agent: It is not tied to a logical agent, it does not have an outbound connection, and it does not have a local database connection or an instance attachment.
The inactive agent is a worker agent which is not in an active transaction, is not tied to a logical agent, does not have an outbound connection, and does not have a local database connection or an instance attachment. An inactive agent is free to tie to another logical agent to begin serving the application represented by that logical agent.
Each process/thread of a client application has a single active coordinator agent that operates on a database. Once the coordinator agent is created, it performs all database requests on behalf of its application, and communicates to other agents using inter-process communications (IPC) or remote communication protocols. Each agent operates with its own private memory and shares Database Manager and database global resources such as the buffer pool with other agents. When a transaction completes, the active coordinator agent may detach from the logical agent and thus become an inactive agent.
In partitioned database environments and environments with intra-partition parallelism enabled, the coordinator agent distributes database requests to subagents, and these agents perform the requests for the application. Once the coordinator agent is created, it handles all database requests on behalf of its application by coordinating the subagents that perform requests on the database.
When a client disconnects from a database or detaches from an instance the coordinating agent will be:
Those agents not performing work on behalf of any applications and who are waiting to be assigned, are considered to be idle agents and reside in an agent pool. These agents are available for requests from coordinator agents operating on behalf of client programs, or for subagents operating on behalf of existing coordinator agents. The number of available agents is dependent on the database manager configuration parameters maxagents and num_poolagents.
Agents from the agent pool (num_poolagents) are re-used as coordinator agents:
Otherwise, remote applications always create a new agent.
If no idle agents exist when an agent is required, a new agent must be dynamically created. Creating a new agent involves a certain amount of overhead and as a result, improved CONNECT and ATTACH performance can be noticed if there is an idle agent that can be activated for a client.
When a subagent is working on behalf of an application, it is considered to be associated with that application. After completing the assigned work, it may be placed in the agent pool, but it remains associated with the original application. When the application requests additional work, the database manager first checks the idle pool for associated agents when finding an agent to work for the application.
The ability to separately control the number of connected applications (using the number of logical agents defined by max_logicagents) and the number of application requests that can be processed (using the number of active coordinator agents defined by max_coordagents) allows for flexibility in the workloads processed at the database. A one-to-one relationship between the number of connected applications and the number of application requests that can be processed is the typical way applications will work with the database. However, it may be that your work environment is such that you require a many-to-one relationship between the number of connected applications and the number of application requests that can be processed.
Since the database global resource overhead is associated with the active coordinator agents, the greater the number of these agents means there is a greater chance that the upper limits of available database global resources will be reached. You may want to allow more connected applications than active coordinator agents so that the upper limits of available database global resources are not reached. By setting the value of max_logicagents greater than the value for max_coordagents, you are concentrating your database work.
Refer to DB2 Connect User's Guide for more information and examples of how to use DB2 Connect as an XA transaction support concentrator.
When working in an environment requiring the use of DB2 Connect to connect to remote systems there is an outbound connect pool. This connection pool reduces the connect time (following the first connection) to a host. When a disconnection from a host is requested, DB2 Connect drops the inbound connection but keeps the outbound connection to the host in a pool. When a new request is made to connect to the host, DB2 Connect reuses an existing outbound connection (if available) from the pool.
| Note: | When using connection pooling, DB2 Connect is restricted to inbound TCP/IP and to outbound TCP/IP and SNA connections. When working with SNA, the security type must be NONE for the connection to be placed in the pool. |
With connection pooling, the active agent does not close its outbound connection following disconnection, but goes into the agent pool with an active connection to the remote host. This type of agent is called inactive DRDA agent. The pool of inactive DRDA agents is a synonym for the outbound connection pool.
Consider the following examples based on four different usage and workload requirements:
With these conditions, the system administrator should configure MAX_COORDAGENTS to 55 since he knows that the maximum number of users what will ever try to connect through DB2 Connect at the same time is 55. NUM_POOLAGENTS, the size of the agent pool, should be set to 40 since, at any one time, that is the average number of users connected or trying to connect. This pool size guarantees enough existing remote database connections to satisfy all inbound clients without having to establish any new ones except when the workload peaks.
For partitioned database environments and environments with intra-partition parallelism enabled, each partition (that is, each database server or node) has its own pool of agents from which subagents are drawn. Because of this pool, subagents do not have to be created and destroyed each time one is needed or is finished its work. The subagents can remain as associated agents in the pool and be used by the database manager for new requests from the application they are associated with.
The following database manager configuration parameters affect the number of database agents:
This parameter can be useful in an environment in which peak usage requirements exceed system resources (memory, CPU, and disk). In such an environment, the peak load may cause excessive performance degradation because of, for example, paging. You can use this parameter to control the load and avoid the performance degradation.
For partitioned database environments and environments with intra-partition parallelism enabled, the impact to performance and memory costs within the system is strongly related to how your agent pool is tuned:
In addition, if the value of num_poolagents is too small, one application may fill the pool with associated subagents. Thus, when another application requires a new subagent and has no subagents in its associated agent pool, it will "steal" subagents from the agent pools of other applications. This situation is rather costly, and causes poor performance.
For example, if the value of num_poolagents is too large, associated subagents may sit unused in the pool for long periods of time. These subagents use database manager resources that will not be available for other tasks.
In addition to the database agents, there are other asynchronous activities performed by the Database Manager which run as their own process (or thread), including:
For more information on identifying the various DB2 processes, refer to the Troubleshooting Guide.