The database manager uses a set of control blocks called an agent structure (or real agent) to service requests from multiple users accessing a common database.
There are always at least two agent structures created: the Operator and the Checkpoint agents. (The initialization process is executed under the Operator agent. The checkpoint agent is activated whenever a checkpoint is to be taken.) In single user mode, there is also a User agent structure under which the user's SQL requests are executed. In multiple user mode, one or more real agent structures are allocated; the number is equal to the value of the NCUSERS initialization parameter.
There are differences in agent handling between single and multiple user mode.
In single user mode (SUM) this process is quite simple. There are three agents created: the Operator, Checkpoint, and User. At initialization time, the Operator agent performs the initialization functions. When initialization is complete, it becomes dormant and control is passed to the User agent, which is said to be "dispatched". The User agent executes until a checkpoint or archive is required, at which point the Checkpoint agent is dispatched, and the User agent waits until the checkpoint has been completed.
The User and Checkpoint agent alternate until the User agent finishes its work. Then the Checkpoint agent performs a final checkpoint and the Operator agent shuts down the application server.
In multiple user mode (MUM), when initialization has been completed, all the user agents start dormant. When a user first issues an SQL statement, a connection is established between the user and the database manager. The connection remains in effect until an explicit or implicit (COMMIT WORK RELEASE) release occurs.
In VSE, a batch user is connected to the application server by connecting a batch partition directly to a real agent in the database partition. An interactive user is connected to the server by establishing at least one link between the CICS partition and a real agent in the database partition. A remote DRDA user is connected to a pseudo agent in the server. The pseudo agent then connects to a real agent when one becomes available (refer to Pseudo-Agents).
In an IBM VM system, a connection is established between the user machine and a pseudo-agent in the database machine. The pseudo agent then connects to a real agent when one becomes available (refer to Pseudo-Agents).
In both VSE and VM the number of real agents is determined by the DB2 Server for VSE & VM initialization parameter NCUSERS. If you have the resources to support more users, increase NCUSERS. For example, ten users want to share the server, but there are only four real agents available. Six users must wait for one of the four to finish a logical unit of work before they receive access to a real agent. If you have the processing power to concurrently service all ten, there is no reason to make some wait.
However, remember that by increasing the level of concurrency in your system, you are also increasing overhead. Each additional real agent requires a minimum of 110KB of storage and, if you use the default size for your buffer pools, an additional 18KB of storage (four 4KB local buffers and four 512-byte directory buffers). Additional real agents can also:
Use the SHOW CONNECT or SHOW USERS operator command to see how many real agents are in use, and when appropriate how many pseudo agents are waiting for real agents. If all your real agents are never in use at the same time, you should reduce NCUSERS to save resources. If you consistently have more than five pseudo agents waiting for a real agent consider increasing NCUSERS by one if you have the resources to support an additional real agent. Refer to page ***.
For CICS users, refer to the performance indicator discussion under the heading CICS.
Before a CICS user can access your application server, you must establish at least one link between the CICS partition and the database partition.
The CIRB transaction defines one or more links, each of which is exclusively attached to a real agent until it is terminated by the CIRT transaction.
Because each link requires its own real agent it is important to establish an appropriate number of links. If you establish too many links for the number of concurrent users you expect to access your server through CICS, you will needlessly tie up real agents, and the resources they require. However, if you do not establish enough links, CICS users will be forced to wait for a free link. As well as causing a delay, not having enough links increases your overhead. Storage and processor time are consumed to concurrently manage these links. CICS must manage all the links in a queue and select one user each time a link becomes available.
To help you decide whether you should err on the side of too many links or not enough, consider which resources are more constrained, -- those of CICS or those of your application server. If CICS resources are constrained, increase the number of links. If your server's resources are constrained, decrease the number of links.
There are two tools for CICS links, the CICSPARS/VSE report, and the CIRD transaction. The CICSPARS/VSE report presents historical information on how many waits for links occurred during a monitoring interval. In contrast, the CIRD transaction provides a snapshot of the same information.
Pseudo-agents allow many users to share, but not concurrently, a few real agent structures. This saves a significant amount of storage because each real agent requires a minimum of 110KB of storage, a pseudo-agent uses less than 600 bytes. (The 110KB value increases depending on how the real agent is currently being used, refer to the DB2 Server for VM System Administration or the DB2 Server for VSE System Administration manuals.)
| Differences between VM and VSE |
|---|
|
While pseudo agents are always used in a VM system, they are only used in a VSE system for remote DRDA users. |
When a user CONNECTs to an application server, that user is allocated a pseudo-agent. The pseudo-agent is assigned to a real agent (assuming one is available) when the user sends an SQL statement to the server. If all real agents are in use, any users having sent messages to the database machine have their pseudo-agents placed on a "wait" queue until a real agent is available. A real agent becomes available whenever an active user (one whose pseudo-agent already owns a real agent) completes a logical unit of work.
Table 3. Real and Pseudo Agents
|
| Real Agent | Pseudo Agent |
|---|---|---|
| Storage per Agent | Minimum 110KB | 600 bytes |
| Number (VM) | NCUSERS (DB2 Server for VM initialization parameter) | MAXCONN - minidisks - # of active Stored Procedure Servers - 1 (CP directory) |
| Number (VSE) | NCUSERS (DB2 Server for VSE initialization parameter) | RMTUSERS (remote DRDA users) |
| When assigned | At SQL command request | At CONNECT |
| When freed | End of LUW | End of connection |
| When no agents are available | Pseudo agent waits in FIFO queue | No connection, error message |
Guest Sharing: With Guest Sharing, the DB2 Server for VSE Online Resource Adapter, running under the control of CICS, can establish the number of communication links specified during online Resource Adapter Initialization. Each of the links is associated with a pseudo-agent to which a real agent is permanently assigned. These pseudo and real agents are not available to other users until the Online Resource Adapter is terminated.
| Note: | For CMS users to simultaneously access the database, NCUSERS must be greater than the number of CICS links. |
The only reason you would want to restrict the number of pseudo agents is to send an error message to a user indicating that no real agents are available instead of putting this user in a queue.
If this is not a problem, set the number of pseudo-agents to the maximum number of users that could possibly wish to connect to the application server at one time. The virtual storage requirement of 600 bytes per connection should be negligible.
The number of pseudo-agents allocated is equal to the value of MAXCONN specified in the CP directory minus the number of CMS minidisks used for the database machine and minus one for the connection to *IDENT.
Pseudo-agents are not used for CICS users nor are they used for batch partition users. However, they are used for remote DRDA users. The RMTUSERS initialization parameter sets the number of pseudo agents available to remote DRDA users. This limits the number of remote DRDA users that can access the server at any one time because each DRDA user requires one pseudo agent. To calculate the number of real agents that can be shared between remote DRDA users, subtract the number of active batch partition users and the number of CIRB initiated CICS connections from the number of real agents (NCUSERS). For example, consider the following:
This means that there are three (10-5-2) real agents that must be shared between as many as 20 pseudo agents (each connected to a remote DRDA user).
You can specify that a remote DRDA user is privileged. Normally, a remote DRDA user is assigned one pseudo agent during the time it is connected to an application server, and shares the available real agents with the other pseudo agents. It always releases a real agent at the end of a logical unit of work (LUW) (refer to Agents). However, a privileged remote DRDA user holds a real agent until it disconnects from the server. Only specify a user as privileged if you expect it to constantly submit work to the server. For example, large batch applications. Interactive applications are not good candidates.
To specify a privileged remote DRDA user, you need to update the LOCALAXE entry in the DBNAME directory for that user. For instructions, refer to the DB2 Server for VSE System Administration manual.
You can use the SHOW USERS operator command to look for consistently free pseudo agents. This indicates that you could probably reduce MAXCONN for VM, or RMTUSERS for VSE. However, constantly busy pseudo agents may indicate that you should increase them.
The most effective indicator that either parameter is set too low is to look for complaints from your users that they cannot connect to the application server. They will receive SQLCODE=-933 with SQLSTATE=57030.
Real agents are placed in a queue and wait there until they receive a slice of the processor time from the database manager (referred to as being dispatched). Before an agent is dispatched, it must:
After each dispatch, the agents in the queue are reprioritized so that shorter LUWs are moved to the top of the queue. "Special purpose" or "system" agents, such as the operator or checkpoint agents, are not reprioritized after each dispatch; rather, they permanently reside at the top of the dispatch queue so that they receive the highest priority assigned to any agent.
Fair Share Auditing is invoked at regular intervals, during which the dispatch queue is scanned for a "deprived" agent and, if one is found, it is moved to the top of the queue. A deprived agent is one that has referenced the buffer pools less than a calculated fair value. This value is based on the average number of references per LUW and per real agent.
You can affect the frequency of Fair Share Auditing with the DISPBIAS initialization parameter. You can set it from 1 to 10 and it defaults to 7. The higher the number the less frequent the audits. A setting of 10 causes short LUWs to be strongly favored and long LUWs to be strongly disfavored whereas a setting of 1 causes less favoritism to short LUWs.
While there are no quantifiable indicators for this parameter, you can determine if it needs tuning by listening to your users. Can you differentiate between users that use short LUWs and those that use long LUWs? If people with short LUWs complain, try increasing DISPBIAS. If people with long LUWs complain, try decreasing DISPBIAS.
If there are periods where you only need to support large sequential jobs (for example, an overnight batch window or long DBS utility job), consider running your application server in single user mode (SUM). You will reduce the overhead of both concurrent processing and in communications.
In single user mode, pseudo agents are not created and there is no overhead associated with prioritizing real agents or with fair share auditing. Also, since the application server does not need to communicate with a user machine or partition, you reduce overhead by eliminating the APPC/VM (in VM) or XPCC (in VSE) or TCP/IP conversations.