The connection concentrator is a new feature in IBM DB2 Universal Database, Version 8.0 (DB2 UDB). The new feature addesses the need for handling a large number of incoming connections that have very short-lived transactions but relatively large delays. This feature offers the following benefits:
- System resources are not held up by connections that perform no work (idle connections).
- Agents can switch amoung servicing many client applications because of the multiplexing architecture.
- Server resource limitationas are based on actual transaction load rather than the number of connections .
For example, say you have a Web application where users are connected to the database but are not doing intense transactions against the table records. The connection concentrator allows users to appear connected to the database while the actual database agent is free to service incoming requests.
Some of the scalability and performance enhancements are as follows:
- Fewer system resources are required than for another system running the same load.
- Control structures are split into application-level and agent-level data.
- Less memory (on average) and fewer processes are required per connection.
 |
|
Enable the connection concentrator
Set the following parameters in the database manager configuration to enable the connection concentrator:
- The value of max_connections must be greater than the value of max_coordagents to turn ON the connection concentrator.
- By default the max_connections parameter is equal to max_coordagents and the connection concentrator is not enabled. This parameter controls the maximum number of applications allowed to connect to the instance. The range is [-1; max_coordagents -- 64000].
- The max_coordagents parameter is the maximum number of coordinating agents that can exist in the instance. Each local or remote application transaction is serviced by one coordinating agent.
When the connection concentrator is enabled, max_connections limits the number of user connections, and max_coordagents limits the number of agents serving transactions.
|
|
How the connection concentrator works
DB2 UDB uses a database agent to service connection requests. Each user connection allocates one database agent. The agent is occupied throughout the life of the connection regardless of the workload running across it. With the connection concentrator enabled, the database agent is "hot" only for the duration of an SQL transaction. At the end of the transaction boundary (commit or rollback), the database agent is disassociated with the application. Then the agent is free and ready to service other transaction requests coming from other applications.
Figure 1. Connection concentrator architecture
Dispatcher
The dispatcher is a DB2 process (db2disp), the key component of the connection concentrator. It controls the multiplexing of connections to agents by dispatching incoming connections and transactions to agents.
There are two ways the dispatcher can get an agent:
- Find an inactive agent from the idle agents pool and then pass the connection or transaction request to that agent for servicing.
- If no idle agents are in the pool, then create a new agent if doing so does not exceed the maxagents/max_coordagents limit set in the dbm cfg. Note: If creating a new agent exceeds this limit, then the connection is queued up and waits for the next available agent to service the request.
Each dispatcher can handle up to a few hundred connections. New connections are assigned to a particular dispatcher and stay with this dispatcher throughout the life of the connection.
Agents
Agents are created or moved from servicing one application to another by the dispatcher. Upon transaction commit or rollback, the agent becomes idle and ready to service the requests assigned by the dispatcher.
Database agents are processes named "db2agent" or "db2agentg":
- db2agent is used for DB2 UDB database connections
- db2agentg is used for gateway connections to Mainframe
When the agent is associated with a transaction, the process name shows its associated database name.
For example, a select statement is issued with autocommit off and before commit or rollback is issued. The process listing (ps -ef | grep instname ) will show "db2agent (SAMPLE)," where SAMPLE is the database name that this particular agent is associated with.
Upon commit or rollback, the same process will show "db2agent (idle)."
|
|
Connection concentrator behavior
See the behavior of the connection concentrator.
|
|
Connection pooling vs. the connection concentrator
Connection pooling is associated with the allocation and deallocation of agents. It decides if the agent can stay or not when the connection disconnects.
The connection concentrator is associated with context switching of agents. It decides which application the agents service when the transaction ends.
Connection pooling acts upon connections and disconnections. Connection concentrator acts upon transaction boundaries (commit and rollback).
Connection pooling helps reduce the overhead of creating and terminating database agents. Connection concentrator helps reduce the resources each agent allocates when the connection is idle.
Must connection pooling be ON with concentrator enabled?
Yes, connection concentrator needs connection pooling to be enabled in order to exploit its functionality.
With connection concentrator enabled, upon reaching transaction boundaries, the db2agent is free and ready to service other requests. If there are no incoming requests to be serviced, dispatcher will determine whether this agent can stay or not. This is when pooling comes into play.
If pooling is disabled, then this agent will be terminated because no idle agent can stay when pooling is off. If pooling is on, and if keeping this agent will not exceed the num_poolagents limit, then this agent will be kept. It will wait to service the next request. If pooling is on, and if keeping this agent exceeds the num_poolagents limit, then this agent will be terminated.
The potential problem with having pooling disabled and concentrator enabled is that agents get terminated upon reaching a transaction boundary. The majority of agents will be terminated when a transaction ends. New agents always need to be allocated when a transaction starts. This will create a large overhead of allocation and deallocation of agents upon reaching transaction boundaries, which defeats the purpose of the connection concentrator.
|
|
Tune the agents' parameters to work with the concentrator
A frequent question about the connection concentrator is, "What's a good value to set for max_connections and max_coordagents?"
The answer involves the tuning of agents in the database manager configuration, and the right approach is to tweak and tune. The setting of each parameter depends on your current running system.
My suggestions include:
- Keep your current maxagents, max_coordagents, and num_poolagents settings. Turn on the concentrator by setting max_connections = max_coordagents + 1.
Now the concentrator is turned on and your server's configuration stays the same. So the resource usage and the number of users that can connect to your system should be the same, but fewer db2agent processes are used or spawned.
- Take a database manager snapshot:
db2 get snapshot for dbm
Look for the bottom part of the snapshot output:
Agents assigned from pool = 0
Agents created from empty pool = 4
Agents stolen from another application = 0
High water mark for coordinating agents = 1
Max agents overflow = 0
Hash joins after heap threshold exceeded = 0
|
Look for the "high water mark for coordinating agents" line. This indicates the highest number of agents that existed at any point during the entire time since your instance was started with concentrator enabled.
In a connection concentrator scenario, agents are spawned only when needed for transactions. Thus, this high water mark number is roughly how many agents you need simultaneously at peak when the concentrator is on.
The number will change on a daily basis. Capture this snapshot daily for a week until the high water mark for coordinating agents seems to be stable. That is the minimum number of agents your system should have. You can set your max_coordagents accordingly, using this number as a guide.
For example, if your original max_coordagents is 2000, and with the concentrator on, the high water mark is 500, then I would set max_coordagents to 800 just to be safe.
Then you can increase your max_connections gradually to allow more users to use this instance. At the same time, continue to gather snapshots to see how the high water mark increases as you increase max_connections.
In the end, you should see that you can allow many more users to connect to the instance with the original setting of max_coordagents.
|
|
What happens if the parameters aren't set properly when the concentrator is enabled?
If there's a new incoming request, but all agents are occupied, meaning they're in the middle of transactions that haven't been committed or rolled back, the incoming transaction will appear to hang. This is because no agent is available to service your request, not even one that would return your request with an error message.
When you see situations, such as user requests that appear to hang after the connection concentrator is turned on, your max_coordagents setting might not be high enough.
You can either increase your max_coordagents setting or lower your max_connections setting. If the problem doesn't go away no matter how high your max_coordagents setting is, then examine whether it is a problem involving a lack of commits in the user application. When the application doesn't commit transactions often, then agents are held up. Eventually all agents will be occupied, causing a hang situation. To fix this, the only solution is to make your application commit when each transaction is done. If you cannot correct this problem, then your environment is not suitable for the use of the connection concentrator.
|
|
- The federated parameter cannot be enabled with the connection concentrator on. You must specify Federated=NO in the database manager configuration if you want to use the concentrator.
- DB2 UDB V7 clients cannot take advantage of the DB2 UDB V8 connection concentrator, which only works with V8 clients and local V8 server connections.
|
|
The opinions, solutions, and advice in this article are from the author's experiences and are not intended to represent official communication from IBM. Neither the author nor IBM is liable for any of the contents in this article. The accuracy of the information in this article is based on the author's knowledge at the time of writing.
Learn
- DB2 Information Center: DB2 Connect v8.2 Connection Concentrator: Learn about Connection Concentrator for DB2 Connect working with DB2 for OS390 and z/OS
- DB2 Informaiton Center: Database Agent Management: Learn about agents management in DB2 UDB ESE v8.2
- developerWorks DB2 zone: Learn more about DB2. Find technical documentation, how-to articles, education, downloads, product information, and more.
Get products and technologies
- IBM DB2 Universal Database Enterprise Server Edition V8.2 for Linux: Download a trial version from developerWorks.
Discuss
- developerWorks blogs: Get involved in the developerWorks community.