Re: system-f-vasfull problem on alpha vms 7.1

On Mar 9, 9:13 pm, Bob Gezelter <gezel...@xxxxxxxxx> wrote:
On Mar 9, 11:48 am, Chris Casey <chris.ca...@xxxxxxxxxxxx> wrote:





On Mar 9, 5:33 pm, Bob Gezelter <gezel...@xxxxxxxxx> 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
.

Relevant Pages

  • Re: system-f-vasfull problem on alpha vms 7.1
    ... applications are not receiving these errors but they are seeing image ... activation times of 7 secs plus and increasing slowly. ... The applications are DSM 7.1 based. ... I am keeping an eye on them to decide when I must reboot. ...
    (comp.os.vms)
  • Re: DST - Engine bounce required?
    ... a restart of all the applications relying on /etc/localtime ... The easiest solution would be to reboot the machine in order to ... Was an OS patch applied to fix the DST issue? ...
    (comp.databases.informix)
  • Re: system-f-vasfull problem on alpha vms 7.1
    ... applications are not receiving these errors but they are seeing image ... activation times of 7 secs plus and increasing slowly. ... The applications are DSM 7.1 based. ... a copy of the SHOW MEMORY output would be useful. ...
    (comp.os.vms)
  • Re: How often to shutdown computer
    ... In the old days poor memory management of the operating ... applications from crashing. ... you may still need to reboot occasionally. ... Or, if you want to save electricity, simply shutdown when not in use;-) ...
    (microsoft.public.win2000.networking)
  • Re: MS Flight Sim X
    ... than I need for that sort of work... ... Your OS decision is definately dependent upon the applications ... so old the admin team is afraid to reboot it because it might not start up. ...
    (rec.aviation.piloting)
Loading