- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: SYSGEN parameter PE1, LOCKIDTBL, NPAGEDYN
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
тАО02-09-2010 09:16 AM
тАО02-09-2010 09:16 AM
SYSGEN parameter PE1, LOCKIDTBL, NPAGEDYN
The two GS1280's were more a historic accident than a requirement; we were running on 16 Gb ES 45's. So we are in a processor and memory rich environment. We have 2Gb fibrechannel HBA's and EVA 5000's and it may be that our real deficit is disk IO bandwidth. Recently, as a general performance improvement, it was recommended to us to change PE1 from 0 to 50000 and LOCKIDTBL & NPAGEDYN to some unspecified higher value.
LOCKIDTBL parameter information:
Feedback information.
Old value was 1607680, New value is 1669632
Current number of locks: 1699831
Peak number of locks: 1732608
So we could change LOCKIDTBL to 2000000 from 1600000 and NPAGDYN to 100 Mb from 66 Mb
To me, the NPAGDYN seems to be sufficient as is.
Nonpaged Dynamic Memory (Lists + Variable)
Current Size (MB) 66.75 Initial Size (MB) 66.75 Maximum Size (MB) 288.25 Free Space (MB) 25.92
Largest Var Block (MB) 4.65 Smallest Var Block (bytes) 64
Number of Free Blocks 195987 Free Blocks LEQU 64 bytes 23
Free Blocks on Lookasides 195946 Lookaside Space (MB) 21.01
Obviously the memory involved will have no cost since we have more memory than we will ever use. So the question is will these increases have any positive or negative impact? Any opinions out there?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-09-2010 09:32 AM
тАО02-09-2010 09:32 AM
Re: SYSGEN parameter PE1, LOCKIDTBL, NPAGEDYN
You are not going to see any improvement.
If you do, you could probably already see hints with Kernel profiling, or SPIN LOCK TRACING.
Any significant MPsync burn? Try @SYS$EXAMPLE:SPL !
If you want to burn a CPU, start the dedicated lock manager. That may well provide and overall speedup, and a nice increased lock activity visibility in T4.... assuming you do any significant locking rates at all!
"it was recommended to us to change PE1 from 0 to 50000"
Surely that recommendation came with an explanation as to WHY and what (statistics) to watch to check its effect? Please share.
"it may be that our real deficit is disk IO bandwidth."
Such hunches are often extremely valuable, and founded in real world knowledge/observations. But the challenge is often to exactly explain and quantify.
What do you have so far?
What made you think in that direction?
What do the EVA's report?
What does OpenVMS Report? (T4, XFC, ...)
What kind of IO is taking place? Database (RDB, ORacle,...)? Flat files? RMS Indexed files?...
Ever found/used a hot-file report to help focus?
"we have more memory than we will ever use."
Did you give generously to the XFC?
Hope this helps some,
Hein van den Heuvel
HvdH Performance Consulting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-09-2010 09:35 AM
тАО02-09-2010 09:35 AM
Re: SYSGEN parameter PE1, LOCKIDTBL, NPAGEDYN
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-09-2010 09:59 AM
тАО02-09-2010 09:59 AM
Re: SYSGEN parameter PE1, LOCKIDTBL, NPAGEDYN
If you think that locking or I/O is a limit here (and those can be very reasonable guesses), then look to speed up your I/O path through a shadowed RAM disk or other such, or with up-rating your SAN storage to a faster HBA or to faster DAS storage. (If you can find this hardware; the Alpha boxes tend to lag on available I/O options.) And find which locks are hot. And which files are hot. Where the applications are spending all the wall-clock.
And FWIW, forty-four gigabytes of physical memory isn't all that much memory capacity these days. That's less than a half-populated 1U server can provide.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-09-2010 01:36 PM
тАО02-09-2010 01:36 PM
Re: SYSGEN parameter PE1, LOCKIDTBL, NPAGEDYN
LOCKIDBL and NPAGEDYN are allocation parameters. They change the sizes of data structures. This will only help if those data structures are currently undersized. On the other hand, it will only hurt if allocating resources there will negatively impact somewhere else.
From what you say the structures are not undersized, and there's no resource shortage, so any (reasonable) allocation changes are likely to be benign. Worth doing? Your call.
PE1 may be a different story. It's a behavioural parameter. It controls the migration of lock trees between systems. It's also a "reserved to HP" parameter, so the general rule is "don't touch without very good reason".
In V8.3, lock tree migration isn't anywhere near as much of an issue as it was in earlier versions. Historically, it was possible for large lock trees to "flap" between systems, and migration was rather inefficient, involving the transfer of individual locks. The result was large clusters could experience "pauses" of up to several seconds while a large lock tree moved back and forth between nodes in response to changes in demand. PE1 was the hack used to prevent migration in environments where it was a problem (which were relatively rare).
Lock tree migrations are now much better optimized (large batches of locks) and flapping has been damped down by better heuristics. In general, it's a GOOD idea to migrate lock trees between nodes in response to demand, as local lock traffic is orders of magnitude faster then inter node traffic. As long as you don't notice them, they're not a problem.
So, in your environment, before you mess with PE1, I'd want to see compelling evidence that lock remastering was a performance issue. See MONITOR RLOCK. See also MONITOR DLOCK to see if there's excessive cross node traffic (which is what remastering is trying to reduce).
Even if you find remastering events, they're not necessarily bad. If they're a worry, you may be able to reduce them by moving your workloads around, concentrating processes working with a particular data base on one node to keep the lock traffic in one place.
Remember, if there are "golden" parameter settings which magically and blindly improve performance, they will be default (well, eventually anyway...)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-09-2010 03:23 PM
тАО02-09-2010 03:23 PM
Re: SYSGEN parameter PE1, LOCKIDTBL, NPAGEDYN
Changes to PE1 should only be based on what you see and measure at your site.