poor performance after memory upgrade

[Wim Van den Wyngaert]

Based upon the accounting info :

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)

[Jan van den Ende]

Peter,

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

[Wim Van den Wyngaert]

Jan,

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

[Ian Miller.]

Your working set limit will be reduced to WSDEFAULT on image rundown. The working set limit is the maximum number of working set list entries that can be used i.e. the max number of process and global pages that the process can address. The actual number of pages in your working set is never more than this.

[John Eerenberg]

Peter,

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

[Jan van den Ende]

Wim,

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

[Martin P.J. Zinser]

Hi,

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

[Ian Miller.]

re working set list size reset on image exit - acording to The Book of Ruth (IDSM) the $RUNDWN system service resets the working set list size back to default. The contents of P0 are deleted. Remember WSDEFAULT is the nummber of entries in the working set list not the number of pages in the working set. Lots of image activation and subsequent rundown is best avoided. Installing images is a way of reducing the image activation overhead. It does not prevent the reduction of the working set list etc

[Lawrence Czlapinski]

Peter,
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