Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Too Much Free Memory on a VAX V7.1

 
Robert Gezelter
Honored Contributor

Re: Too Much Free Memory on a VAX V7.1

Janet,

The T4 kit (emphasis "Kit") requires 7.3-2 or later.

The basic data files are fully compatible with earlier releases. In fact, I have used the T4 tools on earlier releases by de-constructing the kit and putting it together manually. The basis of T4 is MONITOR/RECORD, and that is far older than 7.3-2 (actually, it is pre-Alpha and then some),

- Bob Gezelter, http://www.rlgsc.com
Robert Gezelter
Honored Contributor

Re: Too Much Free Memory on a VAX V7.1

Janet,

I took a quick look at the ZIP archive. Did I miss CPU utilization information?

Thank you for all of the data. You said the machine is not using the page files and is dog-slow. What is it doing?

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

Re: Too Much Free Memory on a VAX V7.1

If T4 is in vmsinstall kit format I can easily disect. We do Monitor/Record to a file and it runs all day every day. Reports at night for 24 summary and prime time summary. I sent the prime time summary. It's in the zip file.
Robert Gezelter
Honored Contributor

Re: Too Much Free Memory on a VAX V7.1

Janet,

BTW, I unearthed the tuning DECUS presentation I referred to in an earlier posting. It is with the Fall 1997 DECUS presentations at http://www.rlgsc.com/decus/usf97.html

At the risk of being long-winded, I will re-tell a story from more than a decade ago. I was called by a site, who had an early VAX 6200 system. In those days, memory prices were a few orders of magnitude higher than today. The VP of IS was being told that he needed a significant memory upgrade, and the cost would be about US$ 30,000. He called me to see if there were any alternatives.

A check of his configuration showed that his system was doing a great deal of swapping. Each user had a complete copy of a multi-megabyte image. Some additional research showed that the images could be installed as shareable with many beneficial side effects (e.g., less disk IO, less memory, better caching). The problem was completely resolved in less than one day (I was even able to take lunch). Needless to say, the invoice was for far less than the cost of the proposed, but unneeded and never purchased memory.

Not every performance story is so dramatic, but the overall experience is in line with that particular case. Interestingly enough, the software vendor [name deleted] never did adopt the change I recommended, they continued to tell their customers to purchase more memory.

- Bob Gezelter, http://www.rlgsc.com
Andy Bustamante
Honored Contributor

Re: Too Much Free Memory on a VAX V7.1

Ultimately, you're going to need management and user buy in to make platform changes. If you have new systems sitting around not in use what will it take to get the resources for migration? Are there any vocal complaints about performance? If no one is reporting a problem, then all's quiet and everyone's happy as far as resource allocation is concerned.

The service costs on these systems might be argument for migration, especially if you have hardware on site for migration. Is Rally part of the environment? That could be a significant hold up, although there are paths to migration with appropriate funding and/or time.

You might consider running your monitor files through T4 on an Integrity system. this can provide some nifty pictures for presentation.

As far as current changes, you might try providing steps in a tuning plan, making small quickly restorable changes and moving up to more complicated phases. The "it just works" (and we have no idea of how and why)can leave a good enough level of service in place. If the application is really business critical, I'd really want to be on more recent equipment and a supported version of OpenVMS.

An outside consultant might report the same recommendations with more weight, a common syndrome with some managers. There are performance consultants a plenty here or e-mail me for a few recommendations.

As Hoff points out, if you don't agree with the long term plan and don't feel the position is interesting, consider moving on.


Good luck
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
John Gillings
Honored Contributor

Re: Too Much Free Memory on a VAX V7.1

Janet,

Fragmentation looks fine. The biggest issue I can see is your processes are paging, because of working set constraints. WSMAX, WSEXTENTs and WSQUOTAs are WAY too low. WSMAX is set to 75MB (151604), but you have 3.5GB of memory, of which 80% is free. What is wrong with this picture?

So you paid lots of money for that expensive memory but you're forcing all your processes into 1/4 of it! Not a good ROI.

If you can get one thing past your managers, I'd suggest WSMAX=1500000 and PQL_MWSEXTENT=1500000. This is in line with current AUTOGEN practice. I'd also crank up the UAF WSQUOTAs, if only for username EDA (8196 pages = 4MB that's laughable in this century). It would be simpler to set PQL_MWSQUOTA to (say) 250000. Give them all 100MB so they've got room to do something!

To try and get this across to those who are blocking these simple changes, tell them it's like paying rent on a large warehouse, but walling off three quarters of it, and spending all your time shuffling stored goods around in the remaining quarter to try and make it fit, THEN renting more warehouse space across town to move stuff into because it won't all fit in the quarter you're using, and paying for truck drivers to cart stuff backwards and forwards (indeed with the disparity of memory and disk speeds, it's more like your overflow warehouse is in Antarctica!).

Pull out your iPod nano and explain that it has TEN THOUSAND TIMES the memory that you're allowing your production processes to use, even though there's plenty of space available.

You paid good money for that memory. Please let your system actually use it. You could allow it with some very simple changes in SYSGEN, with virtually ZERO risk. The nice thing about jacking up WSEXTENTs is it's completely self limiting.

Four digit WSQUOTAs were a necessary evil back in the 1980's when 3.5GB of memory cost more than your house, but today when it's a buck fifty at a supermarket checkout it's just plain silly.
A crucible of informative mistakes
oldskul
Advisor

Re: Too Much Free Memory on a VAX V7.1

I want to let everyone know I didn't give up, I've been out of town. I will repond after I catch up. THANK YOU too!
Steve Reece_3
Trusted Contributor

Re: Too Much Free Memory on a VAX V7.1

I'm confused John.

You say:
"The biggest issue I can see is your processes are paging, because of working set constraints. WSMAX, WSEXTENTs and WSQUOTAs are WAY too low. WSMAX is set to 75MB (151604), but you have 3.5GB of memory, of which 80% is free. What is wrong with this picture?"

I don't see any paging to the page files and the EDA processes are only working with WSDEF, not WSQUO or WSEXTent according to the process display. They're page faulting quite a lot, but using next to no working set. I'm confused!
Steve
EdgarZamora_1
Respected Contributor

Re: Too Much Free Memory on a VAX V7.1

Steve, they move to the Modified List first, not to the Page File(s).
oldskul
Advisor

Re: Too Much Free Memory on a VAX V7.1

Steve (and everyone),

The EDA processes are detached "servers" logging in users from our corporate website. User EDA has a wsmax of 151600 but the users that login have a wsmax of 8192. I'm hoping to change that today.