Topic
5 replies Latest Post - ‏2012-04-04T08:38:37Z by SystemAdmin
SystemAdmin
SystemAdmin
17917 Posts
ACCEPTED ANSWER

Pinned topic db2fw in db2v9.7

‏2010-11-24T06:39:00Z |
Hi we have installed db2v9.7 on AIx,could see lost of db2fw applications connected,IS it really needed ,how can we stop this,will this exceed maxagents since i see it keeps on growing,pls advise
Updated on 2012-04-04T08:38:37Z at 2012-04-04T08:38:37Z by SystemAdmin
  • sakumar9
    sakumar9
    79 Posts
    ACCEPTED ANSWER

    Re: db2fw in db2v9.7

    ‏2010-11-24T06:52:18Z  in response to SystemAdmin
    The db2fw threads are DB2 event monitor fast writer threads. Fast
    writers are used for high volume, parallel writing of event monitor
    data to table, file or pipe. The number of fast writer threads
    started for a database is equal to the number of processors on the
    system.
    • SystemAdmin
      SystemAdmin
      17917 Posts
      ACCEPTED ANSWER

      Re: db2fw in db2v9.7

      ‏2010-11-24T09:38:23Z  in response to sakumar9
      can we stop this permanent.Is this mandatory..
      • Oratorio
        Oratorio
        75 Posts
        ACCEPTED ANSWER

        Re: db2fw in db2v9.7

        ‏2011-03-14T13:13:13Z  in response to SystemAdmin
        I'm looking also to stop or reduce the number of these processes

        I have monitoring and automatic maintenance OFF
  • SystemAdmin
    SystemAdmin
    17917 Posts
    ACCEPTED ANSWER

    Re: db2fw in db2v9.7

    ‏2011-11-08T15:29:06Z  in response to SystemAdmin
    I hope this helps...

    The db2fw process is part of an architectural enhancement to reduce over head of event monitoring in DB2 V9.7. There isn't a way to completely eliminate these threads, however, you can set a registry setting that will only have one thread per processor, per database, per machine (in DPF).

    The db2fw threads, as mentioned above, are part of new architecture in V9.7 for event monitoring. This new "Fast Writer" architecture allows for parallel 'fast-writer' threads on the database system as opposed to a single dedicated
    thread. Because of this, any single thread bottlenecks that may have previously occurred (due to event monitor formatting "costs" pushed onto a single agent) are removed.

    These db2fw threads will exist regardless of if an event monitor is enabled. Since there is one process per thread spawned, you can set the DB2_SYSTEM_MONITOR_SETTINGS variable to 1 (having 0 is not a valid option), and
    that will decrease the number of db2fw processes to one per database.

    Example:
    db2set DB2_SYSTEM_MONITOR_SETTINGS="NUM_WRITERS:1"
    db2stop
    db2start

    Example, using a dual-core system with 3 logical partitions (DPF), initially you can see 2 db2fw threads (since the processor is a dual (2) core processor), despite the default event monitor being disabled:

    db2 set event monitor DB2DETAILDEADLOCK state 0
    DB20000I The SQL command completed successfully.

    db2pd -edus

    EDU ID TID Kernel TID EDU Name USR (s) SYS (s)
    =======================================================
    59 47549905889600 32224 db2fw1 (TEST) 0 0.000000 0.000000
    58 47549910083904 32223 db2fw0 (TEST) 0 0.000000 0.000000

    After setting the instance registry setting and restarting DB2 you will see one thread only:

    db2set DB2_SYSTEM_MONITOR_SETTINGS="NUM_WRITERS:1"
    db2stop
    db2start

    $ db2pd -edus

    EDU ID TID Kernel TID EDU Name USR (s) SYS (s)
    ========================================================
    59 47824888654144 3530 db2fw0 (TEST) 0 0.000000 0.000000

    You can find additional details on db2fw on the following link:

    The DB2 process model
    http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.perf.doc%2Fdoc%2Fc0008930.html