| Hmmmmm...
A good bit of this chapter was 'standard' during the pilot
and got changed AFTER the pilot and I never had a chance to look at it
since this update...until this weeks teach with the new material!
So, here are the edits and changes that need to be made to the 'next'
version, but until then the readers may want to update their own notes
with these comments. I don't have access to a current Instructor's
manual, so maybe some of this stuff is handled there.
page comments
xi Update reference of VPA to DECps
xxxii course flow shows lecture going into the appendices of DECps
and VPA. An appendix should NOT be indicated in the course
flow, these are supplemental training material to be taught,
incorporated, extracted or ignored as appropriate.
xxxix last two bullets - This indicates that VPA and DECps can reside
on the same machine, which is not true. Also refers to PCA,
which has been totally removed and placed in the VAXset/DECset
courses.
(This page was in the Pilot version of the instructor's guide.)
1-7 "System Growth and Investment Protection" are vague statements
and are referring to FUTURE configurations. We need to add items
that reference current hardware, i.e. number of CPUs, power of
CPU, amount of memory needed, etc. These could be an expansion
of the first bullet. See old course for a few other items for
this page.
1-8 Application Performance Management --
WAIT! What happened to the System Performance Management stuff?
Many of those items (from old course) are more important than
tuning! such as staffing levels and schedules (on which shift do
you perform backups and hire operators to work?), policies and
procedures for the systems and users, scheduling resources, basic
capacity planning, etc.! Not all of the bullets in the old
course were useful, but MANAGING the system will benefit its
long-term performance better than Tuning. Application
Performance is merely a single step in the larger piece of System
Performance Management!
1-10 Out of place, belongs near page 1-30. There are 4 'dashes' on
the previous page and this is the only one expanded here.
1-17 3rd bullet -- I've mentioned this before and it got skipped.
OTHER is not a class that is DIFFERENT from DETACHED and SUB
PROCESS. It *is* DETACHED--'true' detached. If you run a
DETACHED job and have it query F$MODE(), it will return "OTHER"
as the mode. Order should look like:
DETACHED
- Interactive
- network
- batch
- other (detached job 'other' than Interactive, batch and network)
SUB-PROCESS
1-18 Why does SPM have a "tm" on it and nothing else does? Put the
"VAX SPM" name on page 'ii' with the other trademarks.
1-19 Note: Monitor Pool not implemented on V6.0 nor on ALPHA/VMS.
IRPs, LRPs and SRPs are gone and replaced by a new dynamically
growing region of Non-paged pool.
1-20 Should mention SUBMON, MONSUM, MONITOR command procedures found
in SYS$EXAMPLES and referenced in the Guide to Perf Mgt, page 3-6
(3-8 in 1986 copy).
Also, should mention ALL_CLASSES since it is used in the example
on next pages.
1-21 The example of SHOW ACCOUNTING doesn't match the RECORD TYPES
above it. Please add the sub-types back in (network, batch, etc.)
back in like they were in the old material.
1-29 2nd bullet, change "At" with "After". There is no reason (that I
know of) where feedback data is any "better" during the peak load
than after the peak load.
Also, remove FEEDBACK from the first command, if you start and
stop at SAVPARAMS then that field is never needed. Basically all
that @SYS$UPDATE:AUTOGEN SAVPARAMS phase does is run the data
collector SYS$SYSTEM:AGEN$FEEDBACK.EXE, p3 is never needed.
1-35 I find that the TERMS at the back of the chapter are quite
useful. I earlier suggested having them at the end of the book,
but I'm changing my mind, I like it like this--at the back of the
chapter
$
|
| >================================================================================
>Note 124.3 Performance chapter 1 3 of 3
>SOAEDS::TRAYSER "Seniority means a bigger shovel!" 95 lines 23-SEP-1992 23:12
>--------------------------------------------------------------------------------
> -< Review of chapter 1 (final version) >-
I don't have access to a current Instructor's
> manual, so maybe some of this stuff is handled there.
Current Instructor's Manual is in:
super::$1$dua6:[es$review.vms_performance_v55]
>
> page comments
>
> xi Update reference of VPA to DECps
?? This is the Table of Contents
>
> xxxii course flow shows lecture going into the appendices of DECps
> and VPA. An appendix should NOT be indicated in the course
> flow, these are supplemental training material to be taught,
> incorporated, extracted or ignored as appropriate.
OK.
> xxxix last two bullets - This indicates that VPA and DECps can reside
> on the same machine, which is not true. Also refers to PCA,
> which has been totally removed and placed in the VAXset/DECset
> courses.
> (This page was in the Pilot version of the instructor's guide.)
?? This is a list of references
>
> 1-7 "System Growth and Investment Protection" are vague statements
> and are referring to FUTURE configurations. We need to add items
> that reference current hardware, i.e. number of CPUs, power of
> CPU, amount of memory needed, etc. These could be an expansion
> of the first bullet. See old course for a few other items for
> this page.
The instructor notes here give some items to discuss. The first bullet refers
to selecting a configuration that will give approripate performance and system
reliability. Modeling techniques and capacity planning are important here.
The second bullet relates to selecting a configuration that can provide for
growth.
Seems appropriate to me. What more would you want to say here. This is not the
place to describe how to configure a system. That is in sys net III.
>
> 1-8 Application Performance Management --
> WAIT! What happened to the System Performance Management stuff?
> Many of those items (from old course) are more important than
> tuning! such as staffing levels and schedules (on which shift do
> you perform backups and hire operators to work?), policies and
> procedures for the systems and users, scheduling resources, basic
> capacity planning, etc.! Not all of the bullets in the old
> course were useful, but MANAGING the system will benefit its
> long-term performance better than Tuning. Application
> Performance is merely a single step in the larger piece of System
> Performance Management!
The point is that the last thing you do is tune the system. I don't think we
are really discussing managing the data center.
>
> 1-10 Out of place, belongs near page 1-30. There are 4 'dashes' on
> the previous page and this is the only one expanded here.
I think perhaps the instructor notes should be expanded here.
Rather than move this page it might be more appropriate to discuss the UAF
parameters here and remove the page on the Authorize utility.
Also adding a section on batch queue parameters and file system parameters
would seem appropriate.
I will rework these pages asap and post them through the distribution list.
>
> 1-17 3rd bullet -- I've mentioned this before and it got skipped.
>
> OTHER is not a class that is DIFFERENT from DETACHED and SUB
> PROCESS. It *is* DETACHED--'true' detached. If you run a
> DETACHED job and have it query F$MODE(), it will return "OTHER"
> as the mode. Order should look like:
>
> DETACHED
> - Interactive
> - network
> - batch
> - other (detached job 'other' than Interactive, batch and network)
> SUB-PROCESS
I think you are right about this. Too much is made of process types. I will
rewrite this section.
>
> 1-18 Why does SPM have a "tm" on it and nothing else does? Put the
> "VAX SPM" name on page 'ii' with the other trademarks.
This is an editing issue. The first time a trademark is mentioned in the text
it gets a TM. Legal issue.
> 1-20 Should mention SUBMON, MONSUM, MONITOR command procedures found
> in SYS$EXAMPLES and referenced in the Guide to Perf Mgt, page 3-6
> (3-8 in 1986 copy).
>
> Also, should mention ALL_CLASSES since it is used in the example
> on next pages.
This is a very brief description of the Monitor Utility which is taught in the
sys net string of courses. I would be happy to remove the Classes altogether
and jump right to the command procedure to be run in batch
>
> 1-21 The example of SHOW ACCOUNTING doesn't match the RECORD TYPES
> above it. Please add the sub-types back in (network, batch, etc.)
> back in like they were in the old material.
How about just changing the sentence to read
Use the DCL command SHOW ACCOUNTING to display the activites that are currently
being recorded.
The Accounting utility is also review from sys net. The point of having this
here is really to just say "Oh yes here is another tool."
>
> 1-29 2nd bullet, change "At" with "After". There is no reason (that I
> know of) where feedback data is any "better" during the peak load
> than after the peak load.
As I understand this the whole point is to run SAVPARAMS when the system is
loaded with a representative workload. This is the only phase that must be run
at that time. In other words it is "better" duing the peak load time.
>
> Also, remove FEEDBACK from the first command, if you start and
> stop at SAVPARAMS then that field is never needed. Basically all
> that @SYS$UPDATE:AUTOGEN SAVPARAMS phase does is run the data
> collector SYS$SYSTEM:AGEN$FEEDBACK.EXE, p3 is never needed.
This example came directly from the documentation. See the Guide to Setting Up
a VMS System. That doesn't mean it is right however.
However I have already updated these pages. I will post them shortly.
>
> 1-35 I find that the TERMS at the back of the chapter are quite
> useful. I earlier suggested having them at the end of the book,
> but I'm changing my mind, I like it like this--at the back of the
> chapter
This point is under discussion right now. It would be helpful to know how you
use them in class.
|