- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: poor performance after memory upgrade
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
тАО05-26-2004 08:42 PM
тАО05-26-2004 08:42 PM
Re: poor performance after memory upgrade
Check what the SBOLTON process is doing.
A process is created, some reporting is done using QTP and QUIZ and the process dies. It restarts immediately.
Keeping the process a live instead of restarting it will save you some process creations (1 every 15 seconds).
Install the images but may be it is better to replace the job by 1 program that does the job every 15 secondsn (not using qtp and quiz).
Is the wsdefault of that SBOLTON process sufficient ? If the program needs memory it will need to pagefault BEFORE it gets more memory. By that time, the task is finished.
(I had this problem with a show queue command that was very slow)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2004 01:51 AM
тАО05-27-2004 01:51 AM
Re: poor performance after memory upgrade
you did implement several suggestions, you wrote.
How IS the impact on performance so far?
Wim's last response did wake up another detail.
Your processes ARE running several images in sequence, right?
Then the difference between WSDEFAULT & WSQUOTA can come into play.
WSQUOTA is what you get allocated (at least) during an image run, WSDEFAULT is what you are guaranteed during DCL processing.
Ending an image, you get to DCL, your WS may get decreased, and upon next image activation, it has to increase again. All extra pagefaults...
Setting SYSGEN param PFRATL to 0 (zero) turns this off. It is a dynamic param, so with SYSGEN WRITE ACTIVE you can manipulate it without reboot.
(I just saw that nowadays the default IS 0, so maybe all this is not applicable, but many systems carry long-time inherited params, so, worth checking anyway)
Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2004 03:32 AM
тАО05-27-2004 03:32 AM
Re: poor performance after memory upgrade
Isn't it PFRATH that must be set to 0 ?
If the number of pagefaults per 100 ms is higher that this value (8) then you get wsinc (2400) pages extra. But this means after 0.1 second !!! And if you need e.g. 30.000 pages, you will need a whole second.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2004 03:51 AM
тАО05-27-2004 03:51 AM
Re: poor performance after memory upgrade
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2004 05:51 AM
тАО05-27-2004 05:51 AM
Re: poor performance after memory upgrade
Thanks for posting your stats. I think I have a pretty good idea of your system bottlenecks. From what I see so far, DKA1 is the problem child (I don't know about CPU -- I presume it is okay).
> A few people have mentioned about the frequent image activations.....
When one sees a high hard page fault rate (as is your case) and has enough memory then, in general, image activations becomes suspect.
> What would cause this ??
The way the system is used. Anything from your sylogin.com to the .COM files associated with the application as well as process creation/deletion, etc. will cause this. It has to. That is by design. The question is, is performance acceptable? In your case it is not.
> Can it be improved??
Yes. It just depends on how (in)efficiently your application runs. I find in situations such as yours that, on most systems. it is not the application code itself, but rather the way in which .COM procedures run tasks. Several have mentioned this before.
> Is it the programming??
Of the .COM files? Could well be in your case. Is the application code itself? It could be, but problably not. Don't know for sure.
> Also as you will see am still getting high hard page faults any more ideas??
Looking at the disks on your "Av Disk I/O Queue Length" (which I call Qd) report, your goal should be an average of 0.50 or less. The exception to this would be if you understand the IO on that disk. For example, one of my database disks has a huge Qd. Normally I would work like a banshee to keep Qd below 0.50, but since I have a lot of knowledge of the application, I let it run with a high Qd. I don't even worry about it until it hits double digits. Again, I understand very well how that disk is used.
The question for you is "what is on DKA1?" You'll have to get familiar with how DKA1 is being used. Is DKA1 the system disk? Is so, a number of us have techniques for solving that problem; image activiation may not be the only problem for a system disk; many things are on the system disk. If DKA1 is not the system disk, then your course of action will be different.
Look at Hein's May 22, 2004 17:28:30 GMT post. This is where you want to focus some/most of your activity.
So, what's the deal with DKA1?
john
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2004 06:00 AM
тАО05-27-2004 06:00 AM
Re: poor performance after memory upgrade
the trick is not to speed up ws growth, but to switch of ws shrink.
Ian,
are you sure image rundown always shrinks ws back to WSDEFAULT? I had the impression that the shrinking is done by AWSA - Automatic Working Set Adjustment, under control of the various WSx and PFRx params?
IF you are right, then in an environment like Peter's it will be advisable to increase WSDEFAULT to WSQUOTA for the relevant accounts. (Somebody have the clarifing answer to this?? )
Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2004 06:01 AM
тАО05-27-2004 06:01 AM
Re: poor performance after memory upgrade
if you really want to dig into what XFC is
doing with you memory, have a look at the
XFC SDA extension
$anal/sys
SDA>xfc
XFC>help
Still, installing frequently activated images
should make a major difference in the page fault rate.
Greetings, Martin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2004 08:25 PM
тАО05-27-2004 08:25 PM
Re: poor performance after memory upgrade
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-27-2004 10:59 AM
тАО08-27-2004 10:59 AM
Re: poor performance after memory upgrade
As others have stated, you want to be able to measure user performance. Would be nice to hear an update on the progress you've made.
1. Make a change and observe for awhile whether it helps or not.
2. Since I had a lot of demand zero faults on my most heavily used system, I tried increasing SYSGEN parameter ZERO_LIST_HI which is dynamic. It "improves the performance of allocating such pages". It helped on my system. I would suspect this a low priority activity so would be done when the CPU is not otherwise being used.
3. I would MON PROC/TOPFAULT at a /DISP=x which allows you to note which processes are faulting a lot. You can also @WORKSET.COM to look for candidates for increasing WSDEF and WSQUOTA through SYSUAF. The idea is to give the processes the memory they need more quickly. Since you have lots of memory available, you may even test raising PQL_MWSQUOTA by 10% at a time in SYSGEN which is a dynamic parameter. I don't like raising PQL_MWSDEF because it requires a reboot to change. It would be nice if it didn't. You have a high global page fault rate which is a soft fault. So increasing the WSQUOTA won't necessarily mean the process will consume that much more memory since some of the pages are already in another process(es) memory. The process will just be able to get the pages faster and easier without needing to exceed PFRATH. Lowering PFRATH will increase working sets by WSINC faster but the processes (such as DECW$TE processes won't necessarily increase their working set page count as quickly as WSINC).
4. When you get time, attach a more recent MEM PAGE. Remember to let it run x min. ( a higher number of minutes usually gives a better indication) before your changes during a peak time period. Then restart after your changes and run about x minutes or more after your changes.
Lawrence
- « Previous
- Next »