- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Too Much Free Memory on a VAX V7.1
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-22-2010 12:23 PM
тАО04-22-2010 12:23 PM
Re: Too Much Free Memory on a VAX V7.1
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-22-2010 12:30 PM
тАО04-22-2010 12:30 PM
Re: Too Much Free Memory on a VAX V7.1
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-22-2010 12:48 PM
тАО04-22-2010 12:48 PM
Re: Too Much Free Memory on a VAX V7.1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-22-2010 01:36 PM
тАО04-22-2010 01:36 PM
Re: Too Much Free Memory on a VAX V7.1
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-22-2010 02:16 PM
тАО04-22-2010 02:16 PM
Re: Too Much Free Memory on a VAX V7.1
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-22-2010 02:30 PM
тАО04-22-2010 02:30 PM
Re: Too Much Free Memory on a VAX V7.1
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 10:45 AM
тАО04-26-2010 10:45 AM
Re: Too Much Free Memory on a VAX V7.1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2010 02:32 AM
тАО04-27-2010 02:32 AM
Re: Too Much Free Memory on a VAX V7.1
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2010 06:56 AM
тАО04-27-2010 06:56 AM
Re: Too Much Free Memory on a VAX V7.1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2010 08:19 AM
тАО04-27-2010 08:19 AM
Re: Too Much Free Memory on a VAX V7.1
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.