Notes.ini Entry


Name:
    Schedule_No_CalcStats

Syntax
    Schedule_No_CalcStats=0 / 1

Applies to:
    Servers

Add-on:

    First Release:
      6

    Obsolete since:

      Category:
        Scheduler

      Default:
        0

      UI equivalent:
        None

      Description:
      The Scheduler task is responsible for maintaining the Freetime data. When new calendar entries are created, they need to be added to the freetime database (Busytime.NSF or Clubusy.NSF). This merging of new entries into existing entries for a user has been seen to cause a spike in the amount of CPU used by the Scheduler task.

      The Notes.INI parameter "Schedule_No_CalcStats=1" disables the hourly statistics collection by the Scheduler task. This also applies to Busytime.NSF if clustering is not configured.

      This parameter requires the restart of the Sched task, and only affects the collection of calendar.* statistics. Although the calendar.* stats will not be cleared from the Stats list until the entire server is rebooted, these stats will not be updated once Sched has been restarted..

      Server slowdowns are a result of hourly statistics reporting by the Sched Task. Each hour, the Sched task must iterate through every entry in clubusy.nsf, and perform a NameLookup to validate the user or resource in order to report statistics. These locks are held by a thread in the sched task, where the thread that locks clubusy.nsf for a write (mode six) is always the same Sched thread.

      Keep in mind that the time of the hour during which the locks occur will vary depending on when the Sched task was started. From an NSD, the Sched thread with the lock may have the following call stack: @[ 5] 0x608aeb70 nnotes._ThreadedNAMELookup@48+208 (0,2,0,0) @lookup0.c(1252)

      When taking back to back call stack dumps, you may see that the majority of the thread's time is spent waiting on the separate NAMELookupThread, with occasional instances where the thread is performing File I/O. Since the collection of Scheduler statistics requires a write lock on the database (it uses NSFDbNamedObjectEnum()), this delay can become especially pronounced with a large number of entries, or severe disk I/O latency (i.e. disk queue lengths averaging above 7).

      In one case, this issue occurred in Lock Manager on clubusy when long-held locks caused delays lasting from 3 minutes up to 99 minutes. However, this condition is not specific to clusters (clubusy.nsf), and may happen with large busytime.nsf databases as well. The problem is more likely to occur on clusters because each clubusy.nsf contains all users across the entire cluster.

      Recommendation:
      Set       Schedule_No_CalcStats=1 to decrease CPU usage by the Scheduler task.

      Related Settings:
      RNR_NO_CALCSTATS

      References:
      Technote 1213708
      Scheduler Task using a lot of CPU
      http://www.ibm.com/support/docview.wss?uid=swg21213708

      Lotusphere 2006, Gagnon/Mierswa
      ID 125 - Planning, Managing and Monitoring IBM Lotus Domino Server Performance