HP OpenVMS Systems

ask the wizard
Content starts here

Cannot increase BALSETCNT? Processes swapped out?

» close window

The Question is:

 
I have upgraded from 5.5-2 to 6.2. Carried my
same modparams.dat file application is the same
and the userload is the same. The processer shows
LEFO swapped out.
 
Sho Mem
 
Slot Usage (slots):                Total        Free    Resident     Swapped
  Process Entry Slots                160          43          79          38
  Balance Set Slots                   78           0          77           1
 
I try to raise BALSETCNT only to have autogen tell me
 
 
** WARNING ** - The user-modified value for BALSETCNT of 84
        very likely would have caused system virtual address space to be
        exceeded rendering your system unbootable. You should review
        records pertaining to BALSETCNT, VIRTUALPAGECNT and WSMAX in
        MODPARAMS.DAT; these primarily affect the size of balance slots.
        BALSETCNT is being reduced to 78.
Can you help?
 
 


The Answer is :

 
  Having processes swapped out is not necessarily indicative of a system
  tuning problem -- swapping out processes frees up memory for use elsewhere
  on the system, and can often be preferable to paging or small freelists.
  (Paging out portions of multiple processes can lead to excessive paging
  and to thrashing.  Having sufficient memory on the free list is necessary
  for quick image activations.  Simply swapping out inactive processes can
  be preferable, and can be a far more efficient use of system resources.)
 
  That said, you might also be running out of system space.
 
  Various common structures -- such as the page tables, non-paged and
  paged pool, system data structures, and the executable code of the
  operating system and device drivers -- all occupy system space.  On
  OpenVMS VAX and on pre-V7 OpenVMS Alpha systems, the aggregate size
  of all these structures is limited to a maximum of 2 GB.  (The one
  gigabyte S0 and S1 spaces comprise "classic" system space.  OpenVMS
  Alpha V7.0 and later adds support for 64-bit space, greatly enlarging
  both the process and system portions of virtual address space)
 
  When VIRTUALPAGECNT and BALSETCNT are both set to relatively large
  values on any release of OpenVMS VAX or on a pre-V7 release of OpenVMS
  Alpha, the resulting system data structures required for the page tables
  can be constrained by the size of system space and by the other
  structures located in system space.
 
  If you need larger values for VIRTUALPAGECNT or BALSETCNT than can be
  fit in the currently available OpenVMS VAX 2 GB system space and cannot
  reduce the consumption of other users of system space, then an upgrade
  to OpenVMS Alpha V7.0 or later is recommended -- the OpenVMS Alpha page
  tables have been moved from S0/S1 space to page table space, and (in
  V7.2 and later) the lock manager data structures have been moved to
  64-bit space.  Alternatively, use two or more sets of system parameters
  (and reboots) or two or more systems to allow those (typically few) jobs
  that require large virtual address spaces to operate when necessary,
  and to allow larger numbers of processes at other times.
 

answer written or last revised on ( 20-MAY-1999 )

» close window