We're testing some new software, Maximo, which is a java application
that connects to our DB2 database. The DB2 version is 9.1 FP4.
We've been running into a problem where the db2 unix account exceeds
its process count limit (currently 500). I've been monitoring the
number of DB2 processes for the instance (db2sims) and the number of
appllication connections to the database (db_sims). At one point I
had 255 unix-related processes and 110 database connections (db2 list
applications). We shutdown the applicaiton and I performed the the
same counts. I end up with 255 unix processes, and 0 database
connections. Of those 255 about 110 where db2fmp processes and about
110 where db2agent processes. Is there a reason why these processes
would stick around after the application server is down.

I get the unix process count by running this

ps -aef | grep db2sims | wc -l

db2sims is my instance owner account

I get the database connections count by running this

db2 "list applications" | grep db_sims | wc -l

db_sims is the database name.

Thanks.

In case it matters.

Most of the processes (both db2fmp and db2agent) say (idle) after them
in the ps output.

For example:

db2sims 1790058 864428 0 May 05 - 0:00 db2agent (idle) 0
db2sims 1794156 823458 0 May 05 - 0:00 db2fmp (idle) 0

Short answer: Yes.

Long answer: db2fmp processes are fenced mode processes, which are created by
fenced UDFs or fenced stored procedures. If keepfenced (in previous versions
keepdari) is set to yes in the database manager configuration, those processes
will not be terminated after the UDF or stored procedure is terminated.

The number of open db2fmp processes is controlled by the fenced_pool dbm cfg
parameter. You can either change the value of fenced_pool to a lower value or
you can change keepfenced to no.
Those processes will be there until you shutdown the instance. They won't be
terminated by disconnecting all applications from the database.

The same is true for the db2agent processes, which are the processes handling
the db2 connections. The parameter you want to check out is num_poolagents.

In both cases, I would not set those values too small. You have to take into
consideration that creating processes takes time and if you have a lot of
applications connecting/disconnecting to/from the database, it can become a
performance issue.

You will have to find the right balance between resources and performance
depending on your environment.

Despite all the information above I have to say that 500 as a process limit
for an instance user is way too low. I have never seen a production
environment that uses any other value than unlimited. (What happens, if you
use more than one database within an instance or if you have more than 500
applications connected to the database/s - although you will get errors even
before 500 connections since you are using fenced UDFs and/or SPs.)

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

Thank you. I'll check into all the above when I'm back at
work on Monday. It sounds like this info should help to
solve the issues we're seeing. :-)