[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

556.0. "pool memory expantion" by AXCL04::LAGIOIA (We do ...the best) Fri May 02 1997 07:33

    Hello!
    Our customer has a vax running openvms v6.2 and has this (known)
    problem:
    
    OJVA01:\PPAHUD>sh mem/pool/full
           System Memory Resources on  2-MAY-1997 10:21:34.49
    
    Nonpaged Dynamic Memory      (Lists + Variable)
    ->Current Size (bytes)      14080000    Current Total Size (pages)  27500
      Initial Size (NPAGEDYN)    3520000    Initial Size (pages)         6875
    ->Maximum Size (NPAGEVIR)   14080000    Maximum Size (pages)        27500
      Free Space (bytes)          268032    Space in Use (bytes)     13811968
      Size of Largest Block         5184    Size of Smallest Block         64
      Number of Free Blocks         1024    Free Blocks LEQU 64 Bytes     634
      Free Blocks on Lookasides       66    Lookaside Space (bytes)     26752
    
    Paged Dynamic Memory
      Current Size (PAGEDYN)     3031552    Current Total Size (pages)   5921
      Free Space (bytes)         2229968    Space in Use (bytes)       801584
      Size of Largest Block      2226656    Size of Smallest Block         16
      Number of Free Blocks          114    Free Blocks LEQU 64 Bytes     111
    
    Doing a delete of listprepop.dat and rebooting the systen it clears the
    problem and after around 6 months the problem occurs again.
    
    After 6 months I think that is normal but the customer wants to know if 
    there is "a fix". 
    
    I just need a confirmation.
    
    Best regards
    Domenico
    
    
T.RTitleUserPersonal
Name
DateLines
556.1BSS::JILSONWFH in the Chemung River ValleyFri May 02 1997 09:404
If the customer is running Pathworks then you need to look at the STARS 
article [OpenVMS,PW-VMS] PATHWORKS V5.0 Periodically Consumes Nonpaged Pool

Jilly
556.2no pathworksAXCL04::LAGIOIAWe do ...the bestFri May 02 1997 09:519
    Hello!
    Thanks for your quick answer but they do not have pathworks.
    
    Any other idea?
    
    Tanks
    Cheers
    
    
556.3IPMTXDELTA::HOFFMANSteve, OpenVMS EngineeringFri May 02 1997 11:1612
   There are cases where the self-tuning pool support does cause problems,
   due to the local application loading.

   There exists the potential for changes in this area and (if memory
   serves) there are changes being made, but you will want to pursue this
   through formal channels (such as an IPMT), as someone from engineering
   will likely need to characterize the application load and look at the
   self-tuning data to determine what has happened here.

   The IPMT would likely be relatively low priority, as you appear to have
   a workaround.
556.4BSS::JILSONWFH in the Chemung River ValleyFri May 02 1997 11:3133
    Nonpaged Dynamic Memory      (Lists + Variable)
    ->Current Size (bytes)      14080000    Current Total Size (pages)  27500
      Initial Size (NPAGEDYN)    3520000    Initial Size (pages)         6875
    ->Maximum Size (NPAGEVIR)   14080000    Maximum Size (pages)        27500
->    Free Space (bytes)          268032    Space in Use (bytes)     13811968
      Size of Largest Block         5184    Size of Smallest Block         64
      Number of Free Blocks         1024    Free Blocks LEQU 64 Bytes     634
      Free Blocks on Lookasides       66    Lookaside Space (bytes)     26752

Since the pool is in use you will need to take a look at who/what is using 
the pool.  There are pool leaks in a few different pieces of software.  If 
the customer is running DECNET/OSI then make sure they have the latest 
version with the latest patches.  To see where the pool is being consumed 
you need to look at the packets for the largest % consumer
$ ANA/SYSTEM
READ/EXEC
READ SYS$SYSTEM:SYSDEF
SHOW POOL/SUMMARY/NONPAGE

Once you see what packet type is the largest consumer then you can do a
SHOW POOL/HEAD/TYPE=blah/NONPAGE

This will show you the address of the packet, the size of the packet (in 
decimal) and the 1st 4 longwords in the packet (in hex and in ASCII).  If 
you can't determine anything from the longwords then you'll need to dump 
some of the packets with an EXAM address;^Dsize

The US CSC has some internal tools that can be used to trace who/what is 
allocating pool and not releasing it.  Normally this type of work is a 
billable service to customers unless it is Digital software casusing the 
pool expansion.

Jilly
556.5MOVIES::WIDDOWSONRod OpenVMS Engineering. Project RockFri May 02 1997 12:158
    RE: .1,.2.,3
    note that .0 says that this is a *Known* problem, and the question is
    whether there is a fix to this known problem.
    
    RE: 0.
    What is the reference (STARs for preference) which makes you state that
    this is known ?  It might be worthwhile asking for an update to the
    IMPT case...
556.6IPMTXDELTA::HOFFMANSteve, OpenVMS EngineeringFri May 02 1997 12:4211
  re. 5

:    note that .0 says that this is a *Known* problem, and the question is
:    whether there is a fix to this known problem.

  Folks are aware of workloads where the self-tuning mechanism causes
  problems, and are aware of specific workloads that can cause this.
  Assuming this is not the Pathworks "storm" problem, and is actually
  a problem with the memory management self-tuning, the IPMT will get
  the request into the queue, and will get this particular workload
  looked at to see if this is a new/different failure in the self-tuning.
556.7there isn't much left to manageEVMS::GRANTFri May 02 1997 14:043
    But .4 points out the real problem in this situation. The variable list
    is short and there isn't much on the lookaside lists. Nearly all of
    pool is currently allocated. Step 1 is to find out who has it.
556.8PHXSS1::HEISERMaranatha!Tue May 27 1997 20:1510
|the pool.  There are pool leaks in a few different pieces of software.  If 
|the customer is running DECNET/OSI then make sure they have the latest 
|version with the latest patches.  To see where the pool is being consumed 
|you need to look at the packets for the largest % consumer
    
    fwiw, DECnet/OSI v6.3 ECO6 is the latest and has the memory leak.  ECO7
    is being worked on.
    
    regards,
    Mike