469,328 Members | 1,327 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,328 developers. It's quick & easy.

runaway/zombie fmps slowly starving engine of resources?

aj
DB2 WSE 8.1 FP 5
Red Hat Linux AS 2.1
(LUW)

I am having ongoing issues w/ FMP processes in my DB2 server, and
thought I would ask for opinions.

My dbm cfg KEEPFENCED is set to YES, and I use several very simple
DB2 UDFS (NOT java, I thought they were the problem, and have
eliminated them). The UDFS are simple, in most cases just wrapping
DB2 built-in functions, or returning comma-delimited lists from tables.

Here's the problem: after a while (ranging from days to weeks), a
BUNCH of db2fmp processes get built up. I counted 79 the other day.
Is this normal? Once a bunch of these build up, funny stuff starts to
happen in the database, with things like:
APP_CTL_HEAP_SZ not being big enough (its 512)
sqlccipcdarihandshake errors
maximum number of agents exceeded (then refuses new connections)
sqlerDisassociateWithFmp errors
sqlerGetFmpThread errors
If I bounce the database (and therefore get rid if all the fmps),
the all the errors/symptons go away, until a bunch of fmps build
up again, and it starts all over.

My theory is that all these fmp's are not normal, and are slowly
starving the engine of resources. How many should there be?

If I kill -9 these fmp process, i get db2diag.log messages "A non-EDU
child crashed", which makes me skittish...

Here's an ps -ef example:

oltpfenc 7756 21755 0 07:35 pts/2 00:00:00 db2fmp
,0,0,0,0,1,1,1e010,2,0,1
oltpfenc 7757 7756 0 07:35 pts/2 00:00:00 db2fmp
,0,0,0,0,1,1,1e010,2,0,1
oltpfenc 7758 7757 0 07:35 pts/2 00:00:00 db2fmp
,0,0,0,0,1,1,1e010,2,0,1

They always come in groups of 3, with consecutive PID's...

Any thoughts?

TIA

aj
Nov 12 '05 #1
1 2130

"aj" <ro****@mcdonalds.com> wrote in message
news:10*************@news.supernews.com...
DB2 WSE 8.1 FP 5
Red Hat Linux AS 2.1
(LUW)

I am having ongoing issues w/ FMP processes in my DB2 server, and
thought I would ask for opinions.

My dbm cfg KEEPFENCED is set to YES, and I use several very simple
DB2 UDFS (NOT java, I thought they were the problem, and have
eliminated them). The UDFS are simple, in most cases just wrapping
DB2 built-in functions, or returning comma-delimited lists from tables.

Here's the problem: after a while (ranging from days to weeks), a
BUNCH of db2fmp processes get built up. I counted 79 the other day.
Is this normal? Once a bunch of these build up, funny stuff starts to
happen in the database, with things like:
APP_CTL_HEAP_SZ not being big enough (its 512)
sqlccipcdarihandshake errors
maximum number of agents exceeded (then refuses new connections)
sqlerDisassociateWithFmp errors
sqlerGetFmpThread errors
If I bounce the database (and therefore get rid if all the fmps),
the all the errors/symptons go away, until a bunch of fmps build
up again, and it starts all over.

My theory is that all these fmp's are not normal, and are slowly
starving the engine of resources. How many should there be?
The number of FMPs that can be active at one time when KEEPFENCED=YES is
determined by the FENCED_POOL configuration parameter:

http://publib.boulder.ibm.com/infoce...n/r0000275.htm

If FENCED_POOL is not set, the default value is MAX_COORDAGENTS.
If MAX_COORDAGENTS is not set, it defaults to the value of MAXAGENTS -
NUM_INITAGENTS.
The default value of MAXAGENTS = 200 and NUM_INITAGENTS = 0.

Tuning FENCED_POOL is probably a good idea in your environment, and you may
need to tweak APP_CTL_HEAP_SZ to work with the value that you set.
If I kill -9 these fmp process, i get db2diag.log messages "A non-EDU
child crashed", which makes me skittish...


It's only a bad thing if DB2 is trying to use the db2fmp process at the time
you kill it :)

--
Matt Emmerton
Nov 12 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by David Hane | last post: by
4 posts views Thread by Matthew Groch | last post: by
2 posts views Thread by John H. | last post: by
4 posts views Thread by ctclibby | last post: by
reply views Thread by nisimura | last post: by
4 posts views Thread by db2admin | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by Purva khokhar | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.