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

[Chris Casey]

On Mar 9, 9:13 pm, Bob Gezelter <gezel... at rlgsc.com> wrote:
> 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-Hidequoted 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- Hide quoted text -
>
> - Show quoted text -

Bob

yes, that was just a figure of speech, by freezing I mean unresponsive
to users.
One of the confusing things is that restarting the application does
not resolve the issue. This could be because of global sections that
don't get released even when the application shuts down.

Chris