Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Please help with sample shell scripts
- Thread starter poolboy
- Start date
Install PDT
------------------------------
Scope of PDT Analysis
PDT collects configuration, availability, workload, and performance data
on a daily basis. This data is maintained
in a historical record. Approximately one month's data is kept in this way.
Also on a daily basis, PDT generates a diagnostic report, which is mailed to
the adm user.
In addition to mailing the report, PDT stores a copy in the
/var/perf/tmp/PDT_REPORT file. Before the new
report is written, the previous report is renamed
/var/perf/tmp/PDT_REPORT.last.
While many common system performance problems are of a specific
nature (a system might have too little memory), PDT also attempts to
apply some general concepts of well-performing systems to its search for
problems. Some of these concepts, together with examples of their
application to the operating system, are as follows:
Balanced Use of Resources
In general, if there are several resources of the same type,
then a balanced use of those resources produces better performance.
Comparable numbers of physical volumes (disks) on each disk adapter
Paging space distributed across multiple physical volumes
Roughly equal measured load on different physical volumes
Operation within Bounds
Resources have limits to their use. Trends attempting to exceed those
limits should be detected and reported.
A disk drive cannot be used more than 100 percent of the time.
File and file-system sizes cannot exceed the allocated space.
Identified Workload Trends
Trends can indicate a change in the nature of the workload, as well as
ncreases in the amount of resource used:
Number of users logged on
Total number of processes
CPU-idle percentage
Error-Free Operation
Hardware or software errors often produce performance problems:
Check the hardware and software error logs.
Report bad VMM pages.
Changes Investigated
New workloads or processes that start to consume resources may be
the first sign of a problem.
Appropriate Setting of System Parameters
here are many parameters in a system, and they must be set correctly.
Is maxuproc set too low?
Are the memory-load-control-parameter settings too high or too low?
PDT normally uses less than 30 seconds of CPU time. Daily data collection takes several elapsed minutes.
------------------------------
Scope of PDT Analysis
PDT collects configuration, availability, workload, and performance data
on a daily basis. This data is maintained
in a historical record. Approximately one month's data is kept in this way.
Also on a daily basis, PDT generates a diagnostic report, which is mailed to
the adm user.
In addition to mailing the report, PDT stores a copy in the
/var/perf/tmp/PDT_REPORT file. Before the new
report is written, the previous report is renamed
/var/perf/tmp/PDT_REPORT.last.
While many common system performance problems are of a specific
nature (a system might have too little memory), PDT also attempts to
apply some general concepts of well-performing systems to its search for
problems. Some of these concepts, together with examples of their
application to the operating system, are as follows:
Balanced Use of Resources
In general, if there are several resources of the same type,
then a balanced use of those resources produces better performance.
Comparable numbers of physical volumes (disks) on each disk adapter
Paging space distributed across multiple physical volumes
Roughly equal measured load on different physical volumes
Operation within Bounds
Resources have limits to their use. Trends attempting to exceed those
limits should be detected and reported.
A disk drive cannot be used more than 100 percent of the time.
File and file-system sizes cannot exceed the allocated space.
Identified Workload Trends
Trends can indicate a change in the nature of the workload, as well as
ncreases in the amount of resource used:
Number of users logged on
Total number of processes
CPU-idle percentage
Error-Free Operation
Hardware or software errors often produce performance problems:
Check the hardware and software error logs.
Report bad VMM pages.
Changes Investigated
New workloads or processes that start to consume resources may be
the first sign of a problem.
Appropriate Setting of System Parameters
here are many parameters in a system, and they must be set correctly.
Is maxuproc set too low?
Are the memory-load-control-parameter settings too high or too low?
PDT normally uses less than 30 seconds of CPU time. Daily data collection takes several elapsed minutes.
- Thread starter
- #3
true it gives you a report that will assist you determining problems...long term...
It will not help you correct with an if then else........
If that is what you are looking for..........
I guess we need to know what things you want to correct and monitor.....
Most still is better done manually......after human evaluation... ie out of paging space or low on paging space....evaluate if it is a one time thing...if not increase it...
Not sure what you are looking for....but yes, PDT is a nice report that helps you
see what is happening on your system so you can then go off and do something about it.
It will not help you correct with an if then else........
If that is what you are looking for..........
I guess we need to know what things you want to correct and monitor.....
Most still is better done manually......after human evaluation... ie out of paging space or low on paging space....evaluate if it is a one time thing...if not increase it...
Not sure what you are looking for....but yes, PDT is a nice report that helps you
see what is happening on your system so you can then go off and do something about it.
I have spent some time thinking about this and the only situation I can say I would not mind automated recovery for would be in restarting down print queues. But even that is pushing it -- I don't want some program trying to restart a print queue attached to a server in Ireland if our circuit to Europe is down. Too much can go wrong to leave it up to the machine, and honestly I think if it could be automated it is probably already automated by standard tools.
But if there's some specific thing, let us know.
But if there's some specific thing, let us know.
- Status