Kbase 5756: How to interpret the -y statistics in the log file
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
How to interpret the -y statistics in the log file
910206-SLK01
INTRODUCTION:
=============
This knowledgebase entry describes how to interpret the results of
using the -y (Statistics) startup option.
WHY YOU NEED TO DO THIS:
========================
The -y option is used mainly to analyze potential performance problems
on the client's (each user's) execution; for example, if the user
is complaining that it takes a long time to get from one procedure
to another. It gives statistics on the edit buffer area (-e) and
.srt file that can help you determine if you might need to raise
or lower the startup option.
PROCEDURAL APPROACH:
====================
When you use the -y option to start up each client, all procedure
execution statistics are written to the database .lg (log) file.
The statistics look like the following:
13:08:36 Single-user session begin for joe on /dev/ttyqY.
13:08:39 Edit buffer map (on return to the editor)
13:08:39 Start Left End Size Name
13:08:39 0 0 2868 2868 prostart.p
13:09:09 Edit buffer map (on return to the editor)
13:09:09 Start Left End Size Name
13:09:09 2868 2868 14636 11768 help.p
13:09:09 14636 14636 15032 396 dict.p
13:09:09 15032 15032 21432 6400 prodict/dictf.p
13:09:09 17676 21432 23820 6144 prodict/dbexch.p
13:09:09 23820 23820 28704 4884 prodict/dbexc.p
13:09:09 28704 28704 33568 4864 prodict/dbexone.p
13:09:09 14636 33568 33984 19348 prodict/dbdeff.p
13:09:09 33984 33984 39216 5232 prodict/dbfset.p
13:09:09 39216 39216 39740 524 prodict/dbchgpw1.p
13:09:13 Program access statistics:
13:09:13 Times Bytes
13:09:13 Reads from temp file:
13:09:13 7 29388
13:09:13 Writes to the temp file:
13:09:13 13 80564
13:09:13 Loads of .r programs:
13:09:13 13 80260
13:09:13 Saves of compilation .r:
13:09:13 0 0
13:09:13 Compilation of .p:
13:09:13 1 0
13:09:13 Checks of file with stat:
13:09:13 39 0
13:09:14 Single-user session end. (334)
The map statistics (in bytes) are written to the log file every time
a user returns from procedure execution to the PROGRESS editor.
The start column indicates what was allocated to the edit buffer
before the next procedure is loaded in. Notice at first, there
is 0 bytes used. Then we load prostart.p and this takes up
2868 bytes (indicated by size column), so after getting to
the edit buffer, we have 2868 bytes in edit buffer (indicated
by the end column). The left column indicates the current high-
water mark for the edit buffer (at 0 when you first start
PROGRESS, but is always the same as your previous End column).
If Progress has to swap another procedure out (using the least
recently used method) in order to fit a new .r (procedure) into
the buffer, you will notice that the Start value will be less
than the previous End column (usually they are the same).
A good example of this is the column where the values are:
Start Left End Size Name
15032 15032 21432 6400 prodict/dictf.p
17676 21432 23820 6144 prodict/dbexch.p
Before loading in dbexch.p, PROGRESS had to swap out another
program. If you notice this happening often, it may be
that you have your edit buffer (-e) startup option set too low
or it could be that you need to increase the -D startup option,
which directly relates to the size of the .srt file (the more
pointers we can have into the .srt file, the bigger it can be).
If no swapping is occurring, you might want to decrease the -e
parameter and see if you can get by with it at a lower value.
Below the map statistics, you will see Program access statistics.
Reads from temp file are how many times we had to read from the
.srt file (the overflow area when we cannot fit all the procedures
in the edit buffer area in memory). Writes to temp file are how
many times we wrote a procedure to the .srt file. Next is the
# of times we loaded .r programs (notice that in this example
we wrote to the .srt file the same amount of times that we
loaded .r's). Since the number of procedures we actually
requested was 10 and the number of times we loaded procedures
was 13, we can usually guess that either PROGRESS swapped out
a program least recently used and then when we asked for it
again, it loaded it on more time in the edit buffer.
Saves of compilation .r are how many times we asked to compile
and save a procedure, and compilation of a .p is how many times
when you requested a .p we had to compile it before loading the .r
into the edit buffer (in this example, there was one procedure
that was not pre-compiled). If this is happening often, the
performance problem could be because the user's are not running
pre-compiled procedures and we have to compile every time. The
Checks of file with stat line indicates a relatively time-consuming
system call. Unless you invoke the Quick Request (-q) startup option,
PROGRESS makes a stat call each time a precompiled subprocedure is
called with RUN.
ONLINE PROCEDURES OR UTILITIES:
===============================
None
REFERENCES TO WRITTEN DOCUMENTATION:
====================================
System Administration Guide II Startup Options chapter
Progress Software Technical Support Note # 5756