Notes/Domino Fix List
 |  |
| SPR # KTIS6UFMDR | Fixed in 7.0.3; 7.0.2 FP1; 6.5.6; 6.5.5 FP3 release |  |
Product Area: Server Technical Area: Server Platform: Cross Platform
SPR# KTIS6UFMDR - This provides a fix to avoid a negative impact on server performance and accessibility by the client, due to the NAB Collection being updated by a function call the HTTP server uses during normal operation (NIFSetCollectionAccess). This fix avoids unnecessary updates to the view and the consequential NLCache flush for HTTP access.
Technote Number: 1604742
Problem:
The NameLookup performance fixes for SPRs CMCY6KBQAR and MLUR6P9TAT address
unnecessary updates stemming from NameLookups. (Note that there are still
cases in which NameLookups will need to update the collection.)
What the fixes do
The fixes for SPR CMCY6KBQAR were for all on-box (local) NameLookup calls to
pass the NOUPDATE flag when updating the collection (before they were
unnecessarily passing the UPDATE flag). SPR CMCY6KBQAR is also accompanied by
SPRs JRON6R6MXB, VSEN6QXL8Q, and VPRS6TYRQ9. Please read the SPR list below
for further details.
The fixes for SPR MLUR6P9TAT were for all off-box (remote) NameLookup calls to
pass the NOUPDATE flag when updating the collection (before they were
unnecessarily passing the UPDATE flag). SPR MLUR6P9TAT is also accompanied by
SPRs KTIS6UFMDR, MERS6V7JSE, JPAI6WJP76, BCOE6WHMC2, and JPAI6X9VHY. Please
read the SPR list below for further details.
How to identify these issues
SPR CMCY6KBQAR specifically refers to on-box (local) unnecessary updates
stemming from NameLookups where the UPDATE flag is passed. These stacks are
often identified by the NAMEGetNSModifiedTimeExtended call on the stack
followed by an update collection call.
Next, SPR MLUR6P9TAT is a bit different of a stack to identify. SPR MLUR6P9TAT
specifically refers to off-box (remote) unnecessary updates stemming from
NameLookups where the UPDATE flag is passed. The UBMPin and UBMClock calls are
usually on the NSD. But, there is more to this the problem than just those two
function calls. Those calls by themselves are harmless, but the problem arises
when you are waiting on these calls or performing them quite often. Just those
calls in general do not point specifically to MLUR6P9TAT. It is necessary to
take the whole state of the server into account (what the other threads are
doing/waiting for). To identify this issue, you can look for an update
collection on a task (other than the update task) which eventually leads to
UBMPin or UBMClock.
If you see a NAB Indexing thread the update task toward the bottom of the
stack, this is a normal operation which runs periodically on the NAB to update
records and can potentially cause lockouts. This is a design limitation and
not a bug.
In general, take a look at the stack and see what is attempting to update the
collection. Again, it is necessary to take into account the whole state of the
server. What are the other threads doing? Who is waiting and why?
If you determine this a match for SPR CMCY6KBQAR and/or MLUR6P9TAT, please read
the below section about the SPR list. If this is a case which does not match
either SPR mentioned above and we are still waiting on an Update Collection,
the PMR should be escalated to development with the appropriate information.
The escalation should include multiple NSDs from the slowdown, information
about when the slowdown occurred and for how long, the console log with
statistics (referenced below) enabled, and semaphore debug. Please be sure all
this information is complete.
What ini's can you use to troubleshoot this issue?
Note the fix for SPRs JRON6R6MXB, VSEN6QXL8Q, CMCY6KBQAR, and VPRS6TYRQ9
(NameLookup Performance fixes) must be enabled via the ini parameter
DEBUG_ENABLE_UPDATE_FIX on a per-subsystem basis. In order for the fix to be
fully functional the DEBUG_ENABLE_UPDATE_FIX ini should be set to 8191 (will be
suppressing the unnecessary updates). If further debug information is
required, please use DEBUG_NAME_UPDATE_STATISTICS=1. For more information
please consult the technote entitled "Troubleshooting a Domino Server Hang
after replication of the Domino Directory" (1244315).
The fix for SPRs MLUR6P9TAT, KTIS6UFMDR, MERS6V7JSE, JPAI6WJP76, BCOE6WHMC2,
JPAI6X9VHY must be enabled by setting SERVER_NAME_LOOKUP_NO_UPDATE=1 in the
notes.ini. If further debug information is required, please use
SERVER_NAME_LOOKUP_TRACE_UPDATE=1 (to trace client requests to update) and
DEBUG_NLCACHE_LOG_VIEWFLUSH=1 (to trace NLCache flushes).
An important note: If you enable one set of fixes (either on-box fixes --> SPR
CMCY6KBQAR or off-box --> SPR MLUR6P9TAT fixes) then you should enable both
sets of fixes (both SPR CMCY6KBQAR related and SPR MLUR6P9TAT related fixes).
These hotfixes cannot be built for any version before 6.5.5 for the 6.x code
stream and 7.02 for the 7.x code stream. We strongly recommend upgrading to
at least 6.5.5 FP2, or 7.0.2 FP1, or any release after these (as this will
reduce the need for large risky hotfixes) and then re-evaluating the issue at
hand.
What is the entire list of SPRs and which versions are they fixed in?
Fixed in 6.5.5 Fix Pack 1 and 7.0.2
JRON6R6MXB
VPRS6TYRQ9
VSEN6QXL8Q
Excerpt from the Lotus Domino Release 6.5.6 MR and 6.5.5 Fix Pack 3 fix lists
(available at http://www.ibm.com/developerworks/lotus):
Server
SPR# VSEN6QXL8Q - Cumulative fixes to reduce the number of updates to the NAB.
CMCY6KBQAR
Excerpt from the Lotus Domino Release 6.5.6 MR, 7.0.2 MR, and 6.5.5 Fix Pack 2
fix lists (available at http://www.ibm.com/developerworks/lotus):
Server
SPR# CMCY6KBQAR - Fixed a problem during namelookups. This problem is observed
if you see that the $users, $peoplegroupsflat, and $serveraccess views were
getting rebuilt during the day, causing slowdowns.
Fixed in 6.5.5 Fix Pack 3 and 7.0.2 Fix Pack 1
KTIS6UFMDR
MLUR6P9TAT
Excerpt from the Lotus Domino Release 6.5.6 MR, 6.5.5 Fix Pack 3, and 7.0.2 Fix
Pack 1 fix lists (available at http://www.ibm.com/developerworks/lotus):
Server
SPR# MLUR6P9TAT - Additional stats/events were added to track updates to the
NAB. Provided the ability to filter out clients that either directly or
indirectly created activity on a directory database that would result in view
rebuilds. Those rebuilds would have the side effect of causing a NAMELookup
cache flush and creating a performance bottleneck on the server for all users.
Fixed in 6.5.6
MLUR6P9TAT (fix details provided in above section)
KTIS6UFMDR
MERS6V7JSE
JPAI6WJP76
BCOE6WHMC2
JPAI6X9VHY More >
Last Modified on 12/08/2013
Go back
|