[Info-vax] How to deal with FPG process state :-(

DJ daryljones at att.net
Sat Jan 31 06:40:40 EST 2009


On Jan 30, 11:41 pm, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> Found my alpha to become unresponsive. But from another node, was able
> to do SHOW SYS to find a number of processes in the never before seen
> state of FPG.
>
> Console had the terrible "page file fragmented attempting to continue"
> message.
>
> I tried to STOP/ID the offending IMAP processes to no avail. Tried to
> STOP/ID any other non critical process, but it just made them into FPG
> statis (except for a couple that stayed in COMO).
>
> Question, with an unresponsive system where only services that don't
> require any memory work (SHOW SYSTEM worked, and PINGING the node
> worked), is there anything that can be done to recover that system
> without the big fat HALT comand from >>> prompt ?
>
> Is this a sign that one of my sysgen parameters needs to be adjusted
> (freelim etc ?) to ensure there is alwasy enough memory to be able to
> kill a process, or is this a hopeless case when you have runaway sofware
> like TCPIP Services which started to create processes left and right
> that each go nuts with memory and page file ?
>
>
>
> > 0200136 TCPIP$MOUNTD_1  LEF     10     2042   0 00:00:00.67       953     25  N
> > 20200137 TCPIP$NTP_1     FPG     10  8787983   0 00:00:54.06      1849     38  N
> > 20200138 TCPIP$POP_1     HIB     10    12120   0 00:00:03.41      2974     25  N
> > 2020013B SYSLOGD_1       FPG      6   726954   0 00:04:04.32      2243     35  N
> > 2020013D WWW server 80   FPG      6 11734083   0 01:02:05.22      4818     39  N
> > 20205D47 TCPIP$IMAP_370  HIB     10   929515   0 00:01:54.73     82116     90  N
> > 20205F53 DECW$TE_5F53    FPG      6    22937   0 00:00:05.41      1424     28
> > 20205F54 _FTA28:         LEFO     4       --  swapped  out  --             32
> > 2020035A SYMBIONT_86     FPG      6     4805   0 00:00:08.61      2473     39
> > 202049A0 TCPIP$TFT_BG199 LEF     10    14139   0 00:00:01.47       581     29  N
> > 20205BA3 DNFS1ACP        FPG     10      231   0 00:00:00.03       187     25
> > 20205FA8 _FTA29:         LEFO     6       --  swapped  out  --             30
> > 202060AC TCPIP$IMAP_371  FPG     10    33933   0 00:00:12.78     74376   3594  N
> > 202060AD TCPIP$IMAP_372  FPG     10    21073   0 00:00:06.79     46001   3190  N
> > 202060AE TCPIP$IMAP_373  FPG     10    15720   0 00:00:04.92     32795   3308  N
> > 202060AF TCPIP$IMAP_374  FPG     10     9531   0 00:00:03.38     20218   3243  N
> > 202060B0 TCPIP$IMAP_375  FPG     10     5719   0 00:00:02.10     13923   3194  N
> > 20205AB1 TCPIP$IMAP_376  FPG     10     4015   0 00:00:01.52      5249    849  N
> > 20205AB2 TCPIP$IMAP_377  FPG     10     3049   0 00:00:01.21      3407   1401  N
> > 202060B3 TCPIP$IMAP_378  FPG     10     1798   0 00:00:00.56      1860    233  N
> > 202042CE WWW_SERVE_1     LEF      6       94   0 00:00:00.04       493     25  S
> > 202047D4 SYSTEM          COMO    11       --  swapped  out  --             31
> > 20201BDE SERVER_0005     FPG      6    15077   0 00:00:09.67     22941     22  N
> > 20201ADF SERVER_0004     FPG      6     1334   0 00:00:00.67      2963     22  N
>
> Does anyone know if the limit for those IMAP process would be controlled
> by the UAF parameter
>          /maxjobs ?
>          /maxacctjobs ?
>          /maxdetach ?
>
> (Or which parameter would be suggested as best way to prevent IMAP from
> creating processes without the old one going away first) ?
>
> Since these processes went nuts with memory and page file, I have to
> assume that they were not subprocesses of a single job, so the
> /PRCLM parameter (subprocesses) wouldn't seem to be the limiting factor.

Dear JF Mezei:

Experiencing several processes in the FRP state and the console
telling you "page file fragmented attempting to continue", you need to
increase the page file size or add another page file on another disk
volume. A very good book on the subject is: VMS Performance Management
by James W. Colburn, page 82-83.

A general rule of thumb is that the page file should be enlarged
anytime when the total page file(s) consumption is more than 50% on
average. I would recommend multiple page files on shadow disks. How
large should be the page file? Some people recommend 1.5 times the
total memory to be the total page file size. In other words, if you
have a 2 GB of memory, then your page file should be at initially at 3
GB.

Once the page file is consumed, the VMS system can become not very
responsive. You are ultimately left with the system shutdown. You need
to write DCL programs to keep track of the page file consumption to
tell you when it has consume more than 50% of the page files. You also
need to find out how many IMAP processes are being generated. IMAP
processes are memory hogs!

The email system that I worked on was a VMS 8.3 GS80 where the IMAP
process count was controlled by the email software. However, too many
IMAP processes will consume process slots, RAM, and page file if your
sysgen parameters aren’t set properly. Make sure you have set the
proper size for WSquota and WSextent. If you set WSquota too high, an
increase consumption of the page file can occur.

What you need to do is get the system configured and tuned properly!

I hope this helps!

Regards,
Daryl Jones



More information about the Info-vax mailing list