LO63977: DIRECTORY ASSISTANCE FAILED OPENING PRIMARY DOMINO DIRECTORY NAM ES.NSF, ERROR: INSUFFICIENT MEMORY - NSF POOL IS FULL.

APAR status

• Closed as fixed if next.

Error description

• Server crashed with: PANIC: ASSERT(0) failed at line 2092 in
  file bpool.c after
  error messages: Directory Assistance failed opening Primary
  Domino Directory
  names.nsf, error: Insufficient memory - NSF pool is full.
  Earlier in the
  console.log there are also error messages:
  
  Admin Process: Path: Insufficient memory - NSF pool is full.
  Error opening Directory Assistance Database dirass.nsf, error:
  Insufficient
  memory - NSF pool is full.
  
  This is a standalone Domino server v852_12172009np on Solaris
  5.10. At the
  time, we were running testnsf script with discussion load:
  nbdiscdb with 50
  threads. The database in use for this test was disc1.nsf.
  Transaction logging
  and DAOS had been disabled. During the test, the disc the
  database resides
  experience extremely heavy i/o. Not sure if this crash is
  related to this.
  Memory and CPU use at the time is very low (in comparison to
  other load tests).
  
  After start-up of the server again after this crash, the server
  reports:
  "Unread chunk XXXXX for user admin/SVTREL08 in database
  /data2/notesdata/disc1.nsf is bad. Object XXXXXX. ReasonCode:60"
  - suggesting
  corruption for this database.
  
  NSD attached to SPR. We have a set of memory dumps and iostat
  output available
  and I can arrange to upload the faulty disc1.nsf somewhere if
  needed (2.6 GB)
  
  UPDATE 05 April:
  
  Restarted test with new discussion databases. This time the load
  was only 20
  threads per database (4 databases, a total of 80 threads). Crash
  reproduced
  with the same stack. This time transaction logging was enabled
  on these four
  databases. Uploading trans logs, and Logfmt to network drive
  (emailed dev with
  location). Memory leak in BLK_NSF_POOL  (0x8252) with a total
  mem alloction of
  537919492 bytes, handles: 513  at the time of the crash. Here is
  a graph of the
  memory allocation in Mb of this block throughout the run:
  
  From NSD:
  
  ** Checking BPOOL(ss=1:4) 0x8252 (BLK_NSF_POOL) minsize=1048576,
  membrs=512/512
  Cap 99%
  
  ----------------------------
  
  <@@ ------ Notes Memory -> Usage Summary -> Top 10 Memory Block
  Usage ->
  Memhandles By Size :: (Shared) (Time 03:37:31) ------ @@>
  
    Type  TotalSize      Count    Typename
  -----------------------------------------------------------
  0x8252  537919492        513  BLK_NSF_POOL
  0x82cd  535330816        136  BLK_UBMBUFFER
  0x93ad   54196318       4252  BLK_VA_UNKDESC
  0x93c5   39467384       2108  BLK_NSF_MODIFIED_NOTE_LOG
  0x82cc   28200972        136  BLK_UBMBCB
  0x8219   22555000       2127  BLK_UNK
  0x8472   15733556          1  BLK_DTRACE
  0x93e0   15628490       4216  BLK_OBJECT_REF
  0x834a    9961472         10  BLK_GB_CACHE
  0x8234    8673622       2108  BLK_BITMAP
  

Local fix

• n/a
  

Problem summary

• This APAR is closed as FIN. We have deferred the fix to a
   future release.
  

Problem conclusion

Temporary fix

Comments

• This APAR is associated with SPR# MHAR7YZJUA.
  This APAR is closed as FIN. We have deferred the fix to a
   future release.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

• R851 PSN

     UP