Conference bulova::decw_jan-89_to_nov-90

Last I heard, VMS uses somewhere around 3MB for all of its stuff, and yo
add 1.5MB for each LAVC and DECnet (of which you only have one)


An 8MB VAXstation running VMS/DECwindows IS short of memory for anything
but minimal work.  Running DECdecision or DECwrite will be rather painful
on such a system.


but, alas, there is a solution.  We will introducing new memory 
configurations later this year (send mail if you want more details) which
should help with this problem.  


As for WHAT VMS and DECnet use this memory for, I don't know, but would
be very interested in finding out.....


-bill

    I had a same sort of problem - I had a little VS-2000 with a mimimun
    of memory - and I had no intention of tying it to the cluster -
    and I wanted  to run things such as DECwrite etc.
    
    In the end my system mangler suggested that I set one of the sysgen
    parameters which reduces the number of process that stay in memory. I
    can't remember for the life of me what it was - but suffice it to say
    that it worked ok. Basically it would swap out everything that wasn't
    being used, freeing up the max memory for the active processes. It
    worked - allowing me to run DECwrite or whatever little decwindows
    application I wanted (eg fl_ght...;-) ) 
                                            
    
    Winton                                  

    The parameter is BALSETCNT.  Another thing that might help is to ensure
    that the 6xxx is doing all the network routing, and that all the
    workstations are end-nodes.  A large DECnet db can absorb lots of
    memory. 

    BTW - you'll find that lots of these memory pages are reclaimed when
    other procs/apps are started.  Process trimming will take care of a lot
    of that (eg - when CLOCK is 1st started, it will use up to 1500 pages;
    after other things start, it gets trimmed back to around 400 pages and
    is happy to sit there with no more). 

    For what it's worth, I have an 8 meg/208Mb disk 3100 with VMS 5.1B,
    DECw, VAX DOCUMENT, ALL-IN-1, CDD-Plus, SPM, and DTR installed.  Of
    course, I can't run things all at once, but have no appreciable
    performance problems when using the thing rationally.  Good luck. 

-b

    To get rid of a HIB or LEF job "quickly", reduce LONGWAIT.  That will
    make the process more eligible for swap out, but will not instantly
    swap it out, as you would like.
    
    Be sure your process working set QUOTA is set large enough to give
    good response, and I suggest a large DEFAULT to help start out with
    a lot of memory (instead of trying to auto-adjust more memory).
    
      John

What about SWPOUTPGCNT? This sysgen parameter sets the number of pages to
reduce the process working set to before swapping the process out. Right now
this is set to 500 pages on workstations with the theory being you don't
won't to fault pages in a few at a time when the process is inswapped but it
seems to me that we are wasting alot of pages on idle processes holding on to
either WSQUOTA or SWPOUTPGCNT pages. It would be really helpful if the system
auto-tuned itself well enough so it could identify idle processes and reclaim
almost all their physical memory. It would also be of great benefit to combine
alot of the system overhead processes into a single process because processes
are SO expensive in terms of their physical memory usage.
						Bill

Ok, I seem to be on the track of something here, let me recap briefly:

1. AUTOGEN on workstations may not autogen properly if you are in the
   habit of bringing up a number of applications on a workstation when
   you log in, and have them sit and wait for something to happen.

2. Autogen most certainly will not work properly if you bring up a number
   of applications that are active most of the time (like the trading
   information system that we have installed) and gets input from the
   mouse or the keyboard occationally.

3. VPA will not detect the problem (Memory is scarce but not causing a
   bottleneck, however should future plans indicate an .... etc.).

I have serious problems getting my customers to accept that VMS grabs
5.0 Mb of main memory, leaving only 3 Mb for their application. The
customers considers (contrary to us ?) that VMS consists of VMS, DECnet
and DECwindows. This is espesially true as the traders that use the
workstation NEVER ACCESSES DCL. They are running (according to their
function) a pre-defined set of applications that are started at LOGIN
and killed at LOGOUT. They don't need most of the VMS stuff.

The advise given in the previous notes indicate that VMS should in fact
grab significantly less than 5Mb of main memory. Well, by us it don't. I
need to find out why, and I am prepared to get funding for any (reasonable)
amount of expences in order to find out why. If we need to fyl in someone
competent in DECwindows system tuning from US, then we'll do so (any
volonters ?)

The ideal solution would be to have a VMS "Application Support Environment"
(Hey that makes out to be VASE, that is in Norwegian the word for a thing
that you put flowers in) that contains nothing but the very essential parts
that you need to get an application running. There is such a thing called
VAX/ELN, but I am unshure of how it will work with DECwindows, and it will
require significant reprogramming on our part to port the applications to
ELN anyhow.

So, can anyone explain how I am to reduce the greedyness of VMS+, or should I
cross post this note to the VMS conference ?

Stein_M

  re .5

  I tried the trick with the SWPOUTPGCNT on my workstation.
  Every time a process is swapped out, it's almost immediately swapped
  in again. It seems that some other process needs info from the 
  process' JIB or other control block which is not memory resident.
  I had no things like VPA or so.

  
  re .6
  
  Also try the TUNING conference.
  
  A few days ago there was a pointer to a document called
  
        VMSKIT::SYS$PERFDOCS:DWLAVC.PS
  
  somewhere in a notesfile.
  Haven't read it myself yet, might be interesting.
  
  
      Bert Catsburg.

    >There is such a thing called VAX/ELN, but I am unshure of how it will
    >work with DECwindows, and it will require significant reprogramming on
    >our part to port the applications to ELN anyhow.
    
    Yes, there is a thing called VAXELN. In fact, V4 of VAXELN started
    shipping yesterday. In V4 is a VAXELN DECwindows server, terminal
    emulators, window manager, and XLIB and Toolkit programming libraries.
    Only you now whether a port to VAXELN will require a significant
    effort, but I would tend to doubt it.

    >I have serious problems getting my customers to accept that VMS grabs
    >5.0 Mb of main memory, leaving only 3 Mb for their application. 
    
    The VAXELN runtime system, complete with runtime executive, DECnet,
    DECwindows server, file system, disk driver, etc takes about 2.5 MB. On
    a 4MB system this leaves room very tight for a couple good size
    applications. On an 8MB system, you've got dancing room.

Stein,
	Hi!  I would very strongly recommend that you get out of the habit of
killing OPCOM at the slightest justification.  In V5.2, Security auditing 
depends on having OPCOM running.  If you were to have fixed your customer's
problem this way this time, you would only have had an even bigger problem when
he upgrades to V5.2 ...

There are a number of little things that you could do to improve memory usage.
If you know your pool requirements very, very well, you can trim down the
xRPCOUNTV parameters to only a little above xRPCOUNT - and also NPAGEDYN and
NPAGEVIR - but beware, because if you need more pool than the "V" parameters
then you could get errors!  The saving here is not great (only the system page
table entries if I remember rightly) but it is something ...  While you're at
it, don't have LOCKIDTBL or RESHASHTBL bigger than necessary either ...

In a similar vein, can you reduce SYSMWCNT - the system working set count - at
all?  It might just be preferable in your situation to suffer a very slightly
higher system page fault rate in favour of more user memory.

How big is WSMAX?  Can you trim that back at all?  That would reduce the size
of process headers a little - actually the working set list in the process
header - which might help.  How big is VIRTUALPAGECNT?  Again, keep it to as
small a value as you reasonably can.

That's about all I can add.  You'll have to try them to see if they make any
noticeable difference ...

Cheers,
Tony Pitt
UK Product & Technology Group

    how about posting a "sho mem/full/all" here so we can all comment
    on it, perhaps a "show sys" as well!!

Re: .6

> I have serious problems getting my customers to accept that VMS grabs
> 5.0 Mb of main memory, leaving only 3 Mb for their application.

Whenever I hear a statement like that, I think of something a customer of
mine once said, tongue in cheek.  His remark went something like: "I paid
over $2000 for that 3MB of memory, and I want to know why we're not using
it!"

His point was, a good memory management system treats memory as "that
resource which I use to prevent that horrible activity called paging or
that even more horrible activity called swapping."  So the operating system
should try to make sure every bit is being used, to keep performance as
high as possible.  When you look at it this way, the fact that 5MB is in
use when you're "just running VMS" may not mean much for what will happen
when you start running applications.

And frankly, I don't think it's always true that "You can barely run
DECwindows in 8MB." SEWANE is a 9MB standalone GPX.  I routinely keep
DECwindows Mail, DECwindows Notes, DECwindows EVE, Fileview, 2 terminal
emulators, and the stock quote program running at all times.  I run
DECwrite when I need to create overheads.  I think my system performance is
"adequate." Not "speedy," but I'm not constantly pleading with my boss to
buy me an extra 4 or 8MB of memory, either.

Applications *DO* seem to take forever to start up, and when I have
DECwrite running and switch over to notes or mail, I get several seconds of
paging before the window pops up, but I can live with that, since I'm
usually in "heads down" mode with DECwrite, anyway.  I start everything but
DECwrite from $RUN/DETACHED commands in DECW$LOGIN.COM, and I have 1-minute
delays in the input command files so I can get the session manager up
quickly, pause the screen, and go do something else for a few minutes after
I log in.  I pause the session manager when I go home, so logging in is
necessary only after vacations and power outages.

A description of my environment follows, in case it might help you.

My MODPARAMS.DAT doesn't contain any memory parameter specifications, and I
run AUTOGEN with FEEDBACK whenever I've finished a few days of particularly
heavy usage.  This has increased my pagefile size to 52,000 blocks and
reduced my swapfile to 1300 blocks.  I'm using an RD53 nobody else wanted
as a separate page and swap disk, so I can spare the space (and the extra
spindle helps performance).  WSDEF=4600 and my UAF entry looks like this:

Maxjobs:         0  Fillm:       100  Bytlm:        70000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:        75  JTquota:       1024
Prclm:          15  DIOlm:       100  WSdef:          512
Prio:            4  ASTlm:       450  WSquo:         1024
Queprio:         0  TQElm:        20  WSextent:      4600
CPU:        (none)  Enqlm:       150  Pgflquo:      60000

I do a $ SET WORKING_SET/LIMIT=150/QUOTA=300/EXTENT=351 in the command file
that runs DECW$QUOTE, so it won't upset the working set balancing act when
it kicks in every 30 minutes.  Someone suggested I should try to find
similar settings for other applications by setting PFRATL to 1 and seeing
where the actual working set values settled, but I haven't had time to play
around with this.

Currently, $SHOW MEMORY gives 855 free pages, 179 modified, 3264
permanently allocated to VMS.  $ SHOW SYSTEM shows 8 "system" processes
(including things like NMAIL) with a total of 1309 pages and 13 "user"
processes with a total of 14,470 pages.  The total is more than the 18432
in 9MB, so there is some sharing going on.  But if we take these figures as
reasonable representations of physical memory usage, the system is using
28% or 2.5MB of the 9MB available.

Hope some of this helps,
Steve