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

[Bob Gezelter]

On Mar 9, 11:48 am, Chris Casey <chris.ca... at NTLWorld.com> wrote:
> 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

Chris,

A small, but important point.

There is a good chance that OpenVMS itself is not freezing. What is
quite possibly happening is that the system is thrashing, not frozen.
I have seen this quite a few times and have been generally able to
recover the system without a reboot; however the system is very bogged
down with paging.

I would agree with Volker, that increasing pool is a a good thing.
However, a controlled applications restart is far less disruptive and
dangerous than rebooting the system. There should be a safe way to
shutdown the application and restart it. Until the virtual size creep
is resolved, an application restart is the best palliative.

- Bob Gezelter, http://www.rlgsc.com