Queue for the NAMELookup code to update NameLookup cache is growing too large.

Server crashes with Error Message = PANIC: Insufficient memory due to high number of handles (47377) for shared memory block 0x8360 - BLK_VIEWREG_DATA

Repeated server crashes on HTTP

Server crashes with Error Message = PANIC: Insufficient memory due to high number of handles (47377) for shared memory block 0x8360 - BLK_VIEWREG_DATA

0x8360 502592290 47377 BLK_VIEWREG_DATA this block is allocating 500MB of memeory

The problem is that there are too many view updates occurring in the Domino Directory. These updates get put on a queue for the NAMELookup code to pull off and update the NAMELookup cache with anything that needs to be updated or purged. That queue is growing too large and therefore allocating too much memory.

Queue for the NAMELookup code to update NameLookup cache is growing too large.

This is not a memory leak. The two key metrics to make this assessment indicate all memory allocations are subsequently being freed :
Database.ViewRegister.Summary.Allocs = 477947
Database.ViewRegister.Summary.Frees = 477947


Build: 8.5.1 HF166 (32-bit server)
OS: Windows/2003 R2 5.2 (32-bit) (Build 3790), PlatID=2, Service Pack 2 (4 Processors)
Host Name: Host
Date: Sat Mar 06 11:54:10 2010


############################################################
### thread 59/60: [ nHTTP: 0cf0: 1590] FATAL THREAD (Panic)
### FP=0x493fe324, PC=0x7c8285ec, SP=0x493fe2b4
### stkbase=0x49400000, total stksize=262144, used stksize=7500
### EAX=0x77e49d86, EBX=0x00000000, ECX=0x00000020, EDX=0x00000002
### ESI=0x00001158, EDI=0x00000000, CS=0x0000001b, SS=0x00000023
### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000 Flags=0x00000293
############################################################
[ 1] 0x7c8285ec ntdll.KiFastSystemCallRet+0 (1158,927c0,0,493fe8ac)
[ 2] 0x77e61c8d kernel32.WaitForSingleObject+18 (1158,927c0,0,493feac8)
@[ 3] 0x601b5bf4 nnotes.OSRunExternalScript@8+1300 (258,1)
@[ 4] 0x601b607f nnotes.FRTerminateWindowsResources+975 (1,1010,1,0)
@[ 5] 0x601b64a8 nnotes.OSFaultCleanupExt@24+984 (c06a68,1010,0,0,0,493fedf0)
@[ 6] 0x601b652a nnotes.OSFaultCleanup@12+26 (0,1010,0)
@[ 7] 0x601c1a24 nnotes.OSNTUnhandledExceptionFilter@4+276 (493ffe28)
@[ 8] 0x6018477d nnotes.Panic@4+589 (60d1b26f)
@[ 9] 0x6018485c nnotes.Halt@4+28 (107)
@[10] 0x6010c515 nnotes.AccessAllProtected@0+85 ()
@[11] 0x6004609e nnotes.AccessAll@8+46 (1,1)
@[12] 0x600476c3 nnotes.ProcessGlobalEvent@4+19 (11c2ee8)
@[13] 0x600475e1 nnotes.OSProcessShouldQuit@0+33 ()
[14] 0x77e64829 kernel32.GetModuleHandleA+223 (6010da10,0,0,dddd04d2)

Windows 32-bit and Domino 851

Memory dumps showed poor use of Dpool

This issue is now fixed in Lotus Notes and Domino 8.5.1 FP5 and 8.5.2.

Fix details: SPR# HARL83GB9T

Refer to the Upgrade Central site for details on upgrading Notes/Domino.

As a workaround, revert two settings to return to the 7.x method for each
Enable DEBUG_VIEW_REG_OVERALL_LIMIT
Another change to the behaviour in 8.5 is the size of one of the internal update queues that Domino uses to record pending requests to views. This queue size by default in 7.x is 32K and was increased in 8.x to 64K. This queue is used to temporarily store updates that are pending inclusion into a view. The Name Lookup thread uses what is in the Domino directory plus what is in this queue when deciding what to data to return. Reducing this queue back to its 7.x size of 32K has the effect of not driving NameLookup so hard as to consume more memory than it needs to in order to service name lookup requests.
Enable DEBUG_VIEW_REG_OVERALL_LIMIT=32768

Second recommendation for Server 851 crashing on HTTP was to set the ini variable to
HTTPJVMMaxHeapSize=64M

HTTPJVMMaxHeapSize
Domino HTTP includes a Java Virtual Machine (JVM). Both the JVM and the HTTP process need memory. By default in 7.0.3, the JVM was set to a limit of 64MB, which was set aside from the total space available to the HTTP process. In 8.5 with the introduction of the new XPages feature, the Java demand increased significantly and we now by default allocate 256MB of Java memory which subsequently reduces the overall memory available to the HTTP process. If you are not using Xpages, you can reset the parameter back to the original 7.x setting thereby returning the additional 192 MB to the HTTP task as available memory. By implementing the HTTPJVMMaxHeapSize=64M setting in your server Notes.ini, you are reverting the JVM memory back to the size you had in R7. If you don't use Xpages, it is recommended to take this step. If you do use Xpages, you'll need the 256MB Java heap, so the way you'd tune Domino in that case would be to reduce the number of concurrent HTTP transactions or spread the user load across a cluster.