IBM Support

Agent pooling differences between DB2 version 7.2 and DB2 version 8

Question & Answer


Question

In version 8, the way in which agents are used, pooled, and re-used are different from version 7.

Answer


In Version 7:
When an agent is no longer actively doing work for an application, it will become part of an "idle pool" (Idle pool is controlled by NUM_POOLAGENTS dbm cfg parameter). Agents in this "idle pool" can be re-used by other applications. There are 3 main types of agents in version 7:

  1. an "Active" agent that is currently doing work for an application.
  2. an "Idle" agent that is NOT currently doing work for an application, and is waiting in the idle pool where it can be re-used.
  3. an "Associated" agent, that is NOT currently doing work for an application, and is waiting in the idle pool where it can be re-used, however this agent is still associated with a given application.

Note that only subagents can be associated agents. Coordinator agents, when they are no longer active, lose their connection to the database and become idle.

When there is a requirement from the application to get an agent, there is logic in DB2 for deciding on how it will get this agent. The various methods that DB2 can choose from to acquire the agent are:
  • Take the agent from the application's list of associated agents (only if this is a subagent request from the same application).
  • Take the agent from the idle pool.
  • Spawn a new agent process/thread to be a new agent.
  • Steal the associated agent from another application. (Called an "agent steal").

In Version 8: (with connection concentrator turned OFF)
When an agent is no longer actively doing work for an application, there exists logic to decide about what is the best way to pool this agent. There are 5 main types of agents in version 8:
  1. an "Active" agent that is currently doing work for an application
  2. a "Pooled" agent that is NOT currently doing work for an application and is part of the idle pool, but is still associated with a given application.
  3. a "Pooled" agent that is NOT currently doing work for an application and is part of the idle pool, but is still associated with a given application group.
  4. a "Pooled" agent that is NOT currently doing work for an application and is part of the idle pool, but is still associated with a given database.
  5. a "Idle" agent that is NOT currently doing work for an application, and is NOT associated with any application, application group, or database. This is a truly idle agent.

Thus, when an agent is no longer active, the agent pooling logic will decide how this agent will be pooled (any of 2-5 above).

The decision to terminate agents or to leave them pooled may be delayed by as much as two minutes to buffer volatile agent reuse activity in version 8.1. This may result in the actual number of pooled agents temporarily exceeding NUM_POOLAGENTS.
In version 8.2, this time is reduced to 30 seconds, and there is a special case condition where if NUM_POOLAGENTS is set to 0, then the agent will be freed right away without any delay time.

Type 4. above only applies if INTRA_PARALLEL is turned OFF, and there is only 1 partition (agents are pooled per database in this config)
Type 2. and 3. above only applies if INTRA_PARALLEL is turned ON, or if there are more than one partition (i.e. there can be subagents with this config, and so agents can be pooled in these different ways).
Type 1. and 5. are valid cases for both INTRA_PARALLEL ON or OFF, and does not depend on the number of partitions.

In version 8, pooled agents will be kept as "hot" as possible. By this, I mean that DB2 can avoid the overhead of initializing application information, application group information, and database information for an agent because the pooled agent would already have this information initialized. The side affect of this is that pooled agents may "hold on" to more memory than in version 7. See the related technote on "Increased DB2 private memory usage on version 8 in the Application Heap" for details on the memory issues for agents in version 8.

When there is a requirement from the application to get an agent, the logic for deciding how it will get the agent will choose from one of the following:
  • Take a pooled agent that is associated with the given database (INTRA_PARALLEL off, and single partition case only).
  • Take a pooled agent that is associated with the given application (INTRA_PARALLEL on, or multiple partition case).
  • Take a pooled agent that is associated with the given application group (INTRA_PARALLEL on, or multiple partition case).
  • Take an idle agent.
  • Steal a pooled agent that is associated with another application or application group (INTRA_PARALLEL on, or multiple partition case).
  • Spawn a new agent process/thread to be a new agent.

[{"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Performance - General\/Tuning","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8","Edition":"All Editions","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
16 June 2018

UID

swg21175496