db2 本人一窍不通，最近db2fm 这个进程竟然老占到100%cpu。不知道怎么会事？
有高人指点一下么？。

这个进程是监控用的，可以杀掉，系统默认启动的，会写在/etc/inittab文件中，可以修改为不启动。我也遇到过类似问题，杀掉了事，没发现对系统有什么不良影响。

检查db2补丁和配置

db2stop，看看系统还有什么残留进程，有的话全杀掉，然后db2start

IY64683: DB2FM (FAULT MONITOR) RESPONSIBLE FOR HIGH CPU USAGE ON THE SYSTEM

Fixes are available

DB2 Universal Database Version 8 FixPak 8a (also known as Version 8.2 FixPak 1a)
DB2 Universal Database Version 8 FixPak 9a (also known as Version 8.2 FixPak 2a)
DB2 UDB Version 8.1 FixPak 11 (also known as Version 8.2 FixPak 4)
DB2 UDB Version 8.1 FixPak 12 (also known as Version 8.2 FixPak 5)
DB2 UDB Version 8.1 FixPak 13 (also known as Version 8.2 FixPak 6)


APAR status
Closed as program error.

Error description This problem is caused by db2fm consuming agreat deal of CPU resource, which leads to unexpectedly high CPUusage on the system.Local fix If you do not need to have the fault monitor running,you can disable the fault monitor completely by doing thefollowing:Edit the db2fmcd entry in /etc/inittab to prevent it fromrespawning automatically:Change: fmc:2:respawn:/usr/opt/db2_08_01/bin/db2fmcd #DB2 FaultMonitor CoordinatorTo:  fmc:2nce:/usr/opt/db2_08_01/bin/db2fmcd #DB2 FaultMonitor CoordinatorKill the existing db2fm and db2fmcd processes with signal 9. Forexample: kill -9 <process ID for db2fm or db2fmcd>Problem summary Users AffectedB2 UDB Version 8.1 FixPak 7 and FixPak 8. If this problem hasnot been encountered soon after upgrading to Version 8.1 FixPak7 (Version 8.2), you are not likely to be affected. If you haveencountered this problem, you might also be affected by APARIY66728.Problem Description: DB2FM(fault monitor) responsible for highcpu usage on system.Problem Summary: db2fm spins in an operatig system cryptionroutine.Problem conclusion  The complete fix (IY64683) for this problemfirst appears in DB2 UDB Version 8.1 FixPak 9.Temporary fix Comments

APAR information
APAR number	IY64683
Reported component name	DB2 UDB ESE AIX
Reported component ID	5765F4100
Reported release	810
Status	CLOSED PER
PE	NoPE
HIPER	YesHIPER
Special Attention	NoSpecatt
Submitted date	2004-11-12
Closed date	2005-05-26
Last modified date	2006-02-16

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

Publications Referenced

[tr][/tr]

Fix information
Fixed component name	DB2 UDB ESE AIX
Fixed component ID	5765F4100

Applicable component levels
R820 PSY	UP

[ 本帖最后由 darkbug 于 2007-6-4 10:40 编辑 ]

为什么db2fmd进程占用太多CPU资源？

Document #: 1897545K25001

Body:
[标题] 为什么db2fmd进程占用太多CPU资源?

环境:
产品：DB2 UDB ESE
平台：跨平台
版本：V8

问题描述: DB2故障监控程序db2fmd占用太多CPU资源

解答:

DB2故障监控程序db2fmd会定期检查DB2实例的活动状况，该程序的配置文件位于实例目录$INSTHOME/sqllib/下，文件名为fm.<主机名>.reg。内容如下：

FM_ACTIVE = yes # default
START_TIMEOUT = 600 # default
STOP_TIMEOUT = 600 # default
STATUS_TIMEOUT = 20 # default
STATUS_INTERVAL = 20 # default
RESTART_RETRIES = 3 # default
ACTION_RETRIES = 3 # default
NOTIFY_ADDRESS = db2inst@p615 # default

db2fmd会每隔STATUS_INTERVAL时间检查一下DB2实例的活动状态，如果STATUS_INTERVAL设置太短，如设置为0，会导致该程序频繁检查DB2实例的活动状态，从而占用过多的CPU，您可以根据您的需要设置为合适的时间，其单位为秒。可以直接编辑该配置文件或者db2fm命令修改，如过我们打算设置STATUS_INTERVAL为50秒，那么可以使用如下命令：

db2fm -i db2inst1 -I 50/20

该命令将STATUS_INTERVAL设置为50秒，STATUS_TIMEOUT设置为20秒。下面的配置文件为设置后的内容（注意斜体字的一行已经修改为50秒）：
FM_ON = no # default
FM_ACTIVE = yes # default
START_TIMEOUT = 600 # default
STOP_TIMEOUT = 600 # default
STATUS_TIMEOUT = 20 # default
STATUS_INTERVAL = 50 # updated by db2fm
RESTART_RETRIES = 3 # default
ACTION_RETRIES = 3 # default
NOTIFY_ADDRESS = db2inst1@p615 # default

问题已经解决
谢谢darkbug
等下把解决办法写上来，现在上班。

1、db2fm -s -S  
Gcf module 'fault monitor' state is AVAILABLE
Gcf module '/home/test/sqllib/lib/libdb2gcf.so' state is AVAILABLE
杀db2fm后，并重起。
1、注释/etc/inittab中的fmc
2、ps -ef|grep db2fm
kill -9 db2fmcd (Fault Monitor Coordinator Daemon (FMCD)), db2fmd (Fault Monitor Daemon) or db2fm (Fault Monitor)
3、将/etc/inittab的注释去掉
4、以ldap用户登录，执行：
db2fm -i instance_name -U
db2fm -i instance_name-u
db2fm -i instance_name -f on
5、db2fm -s -S再看下状态是否正常

学习了！