By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,854 Members | 856 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,854 IT Pros & Developers. It's quick & easy.

How to terminate idle agents?

P: n/a
DB2 UDB V8.2 on AIX. Is there a db2 command/function to terminate a
single idle agents from the agent pool. I could kill -9 the process
but I was wonder if there was a more graceful or appropriate way to do
this. I did not see an API call like sqleEndCtx that could
perminently remove the agent and clean up memory. Any ideas?
Jun 27 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
An add to this..it looks like kill -9 of any of these idle db2agent
processes kills all of them and then shuts down db2 so that wont work.

Jun 27 '08 #2

P: n/a
Ian
shorti wrote:
DB2 UDB V8.2 on AIX. Is there a db2 command/function to terminate a
single idle agents from the agent pool. I could kill -9 the process
but I was wonder if there was a more graceful or appropriate way to do
this. I did not see an API call like sqleEndCtx that could
perminently remove the agent and clean up memory. Any ideas?
How much memory are you talking about for each agent? DB2 agents attach
to the database shared memory segment(s), so `ps` makes each agent look
like it's using a lot of memory. Killing an agent would not deallocate
the shared memory segment -- and, as you found out, it will crash the
instance.

Typically the agents have a relatively small amount of private memory
when they are idle.

If you're seeing agents with lots of allocated private memory (i.e.
using a tool like db2mtrk to see this), you have a few options:

1) If you don't want idle agents sitting around, consider setting
NUM_POOLAGENTS to a smaller value.

2) Also, check the DB2MEMDISCLAIM and DB2MEMMAXFREE registry variables
to make sure that they are not set inappropriately. (the default
value of these variables, which you won't see if they haven't been
set for your instance, are YES and 8388608, respectively.
Jun 27 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.