[Info-vax] system-f-vasfull problem on alpha vms 7.1

[Chris Casey]

On Mar 9, 5:33 pm, Bob Gezelter <gezel... at rlgsc.com> wrote:
> Chris Casey wrote:
> > Hi guys,
>
> > I am having some performance issues and at the same time seeing the
> > above errors when doing common functions such as sh dev/m. As yet my
> > applications are not receiving these errors but they are seeing image
> > activation times of 7 secs plus and increasing slowly.
>
> > I have spent ages trying to see what is going wrong but have not been
> > able to find too much about this error and its possible causes as all
> > my searches find solutions that only seem to apply to vax vms.
>
> > It takes about 80 days after a reboot for this issue to reappear and I
> > only get a few days to look at it before being forced to reboot.
>
> > I am assuming that it has something to do with some sort of memory
> > laddering but am stuck as to how to track it much further than that. I
> > have been around VMS for longer than I care to remember but have never
> > had to get into the depths of memory issues like this before so am a
> > bit stuck.
>
> > Any pointers on where to start tackling or investigating this issue
> > would be much appreciated as thus far I have gone around in circles.
>
> > I am running Alpha VMS 7.1 on an Alpha 4100.
> > The applications are DSM 7.1 based.
>
> > Chris
>
> Chris,
>
> For a start, a copy of the SHOW MEMORY output would be useful.
>
> Additional information can be gleaned from using ANALYZE/SYSTEM on the
> running system. For a start, look for a process whose virtual size is
> always trending larger (monotonically increasing).
>
> From past experiences, I have seen similar behavior on other systems
> where the page files were getting filled. In those cases, image
> activation (and for that matter, many other things) can be
> dramatically slowed.
>
> - Bob Gezelter,http://www.rlgsc.com- Hide quoted text -
>
> - Show quoted text -

I have review the discussion on itrc and have some of the batch jobs
shown there running.
I have identified that the main application instances (DSM) do appear
to be increasing their FREEP0VA.
I am keeping an eye on them to decide when I must reboot.

I assume that in this way they are also reducing the total available
for other processes as a new login can instantly generate the error by
doing basic commands.

This is the output of the sh mem

Chris $ SH MEM
              System Memory Resources on  9-MAR-2009 17:38:23.26

Physical Memory Usage (pages):     Total        Free      In Use
Modified
  Main Memory (1024.00Mb)         131072      109032
18815        3225

Virtual I/O Cache (Kbytes):        Total        Free      In Use
  Cache Memory                      3200           0        3200

Granularity Hint Regions (pages):  Total        Free      In Use
Released
  Execlet code region               1024           0
796         228
  Execlet data region                168           2
142          24
  S0/S1 Executive data region       1571           0
1571           0
  S2 Executive data region           640           0
640           0
  Resident image code region        1024           0
818         206

Slot Usage (slots):                Total        Free    Resident
Swapped
  Process Entry Slots                352         266
86           0
  Balance Set Slots                  350         266
84           0

Dynamic Memory Usage (bytes):      Total        Free      In Use
Largest
  Nonpaged Dynamic Memory       15491072     1489920    14001152
21888
  Paged Dynamic Memory           3866624     1788816     2077808
1762480

Buffer Object Usage (pages):                  In Use        Peak
  32-bit System Space Windows (S0/S1)              0           1
  64-bit System Space Windows (S2)                 0           0

Memory Reservations (pages):                Reserved      In
Use        Type
Total (0 Mb reserved)                              0           0

Paging File Usage (blocks):                     Free  Reservable
Total
  DISK$ALPHASYS:[SYS0.SYSEXE]
SWAPFILE.SYS
                                               45056       45056
45056
  DISK$ALPHASYS:[SYS0.SYSEXE]
PAGEFILE.SYS
                                             2105216     1764288
2105216

Of the physical pages in use, 5769 pages are permanently allocated to
OpenVMS