If you use the get snapshot command, you can get at the instance level:
number of local agents executing in
number of remote agents executing in
high water mark of agents executing
Take your snapshot at regular intervals and pipe the output to file for
V7 and/or use table functions for V8.
If you find in your output that number of agents stolen increases from
snapshot to snapshot, you'd have an indication the number is too small
I'd worry about the number of pool agents when:
A) Running an SMP enables box with many processors (8+)
or
B) running an OLTP environment with a high rate of trans./sec
Creating agents cycle steals away from DB2 but you'd have to benchmark
carefully to find a significant impact with an average of 30 connections
(by the way are those agents connected in or executing in). If
connected in, they may be idle and be available, unless they are
coordinators.
HTH, Pierre.
David Franit wrote:
Hello,
I am looking at tuning NUM_POOLAGENTS for many v7.x and v8.x UDB instances.
Aside from logging into each instance and running 'db2 list applications',
or writing a script to do so, is there any way to determine the average
number of connections to an instance?
Also, without getting into detailed hardware information, we have many DB2
instances on a server whose bottleneck is usually RAM/paging space as
opposed to CPU. I thought that in such a situation, it may make sense to
set NUM_POOLAGENTS to a very small value.
Has anybody found that performance suffered when NUM_POOLAGENTS was too
small? Perhaps the overhead required to create and release
pool agents may be small enough that keeping NUM_POOLAGENTS small is
tolerable. (The instances usually have 10 to 30 or so connections,
not thousands).
Thanks,
DF
--
Pierre Saint-Jacques - Reply to: sescons at attglobal dot com
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
