Question & Answer
Question
Why does the DB2FMP process take 90% CPU time and the instance hangs?
Cause
Two possible reasons for this high CPU usage symptom:
1) This problem can occur if DB2 runs out of monitor heap. The memory required for maintaining database system monitor data is allocated from the monitor heap. When no more monitor heap is available, the automatic database maintenance functionality (such as automatic backups, statistics collection, and REORG) will take a lot longer because this functionality relies on the fenced routine infrastructure.
2) APAR IY75671. In this case, the slowdown is proportional to the number of databases with a large number of table spaces and containers.
Answer
To resolve this problem, it is very important to find out if the high CPU usage is caused by the APAR IY75671. Normally the high CPU usage should not occur after turning off the auto maintenance evaluations, even with HEALTH_MON set to ON. If the high CPU usage still occurs with auto maintenance turned off, this high CPU symptom is most likely caused by the APAR IY75671 and you may want to consider upgrading the DB2 UDB to the FixPak that includes the fix for this APAR. The APAR IY75671 will be included in DB2 V8.1 FixPak11.
To turn off the auto maintenance evaluations, you can run the following commands:
- db2 update alert cfg for databases using db.tb_runstats_req set thresholdschecked no
db2 update alert cfg for databases using db.db_backup_req set thresholdschecked no
db2 update alert cfg for databases using db.tb_reorg_req set thresholdschecked no
db2 connect to RMDB
db2 update db cfg using AUTO_MAINT OFF
- db2 update alert cfg for database on <DBNAME> using db.tb_runstats_req set thresholdschecked no
db2 update alert cfg for database on <DBNAME> using db.db_backup_req set thresholdschecked no
db2 update alert cfg for database on <DBNAME> using db.tb_reorg_req set thresholdschecked no
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21222682