ProTop
ProTop is a Free Open Source Progress 4GL VST based performance monitoring program. ProTop monitors OpenEdge database performance with an eye towards presenting performance tuning data in an organized, real-time manner rather like the UNIX "top" program than the traditional PROMON style.
New Stuff
- Added new display types for:
- Helpers -- BIW, AIW and APW information
- Connection Summary -- Show Overall hit ratio as well as the breakout between interactive and batch sessions.
- Config and Startup -- Show key configuration and startup details.
- Moved highly variable configuration details from lib/protop.i to etc/protop.cfg.
- Added color coded alert definitions to etc/alert.cfg -- you need a color capable emulator and a proper protermcap to take advantage of this. There is a sample in etc/protermcap.protop.
- R-Code for people who cannot compile ProTop!
- Added OS specific monitoring for Linux, AIX, Solaris, HP-UX
and Tru64!
- df -- Free disk space
- netstat -- Network traffic
- Added experimental "eXtended _Connect" feature to determine UNIX username and CPU time from "ps". Rename mon/xconnect.px to mon/xconnect.p to enable this feature for your system (it may be a performance problem on large systems).
Removed
- Unused scripts
- db, log & util directories -- these currently are too complex for ProTop's mission.
Small Changes
- Changed from %used to %allocated when reporting storage area utilization.
- Minor renaming of display types to better standardize names.
- Cleaned up some column labels and alignments.
- Added a few fields here and there.
- Updates to help files.
- Reorganized OS specific directory tree to be based off "uname -a"
Bug Fixes
- Cleaned up some share locks that somehow crept in
- Fixed the GUI startup bug.
- Fixed the "goslow" bug. Joins of _UserIO and _Connect are now fast.
- Various other small stuff that I didn't keep very good notes about
16:19:25 ProTop xix -- Progress Database Monitor 08/01/06
Sample s2k [/data/s2k] Rate
Hit Ratio: 36:1 58:1 Commits: 252 68 Sessions: 2441
Miss% : 2.744% 1.739% Latch Waits: 6 7 Local: 1095
Hit% : 97.256% 98.261% Tot/Mod Bufs: 125002 5294 Remote: 1072
Log Reads: 217203 237895 Evict Bufs: 31 0 Batch: 1348
OS Reads: 5959 4136 Lock Table: 150016 8 Server: 260
Rec Reads: 98694 110213 LkHWM|OldTrx: 3784 00:00:00 Other: 14
Log/Rec: 2.20 2.16 Old/Curr BI: 299 299 TRX: 28
Area Full: 3 99.99% After Image: 0 of 16 a14 Blocked: 0
Orders: 25 1 GL Entries: 29 0
The top line of the Summary displays the current time, ProTop release information and the date.
The second line shows the state of the Sample/Summary variable, the logical and physical name of the current database and the state of the Rate/Raw variable.
Sample/Summary determines if data is presented in terms of the values seen in the most recent sample or as a summary since ProTop was started. The "s" and "S" commands toggle between the two values. Sampling ("s") is the default. Most Summary Screen data elements are shown as both -- the first element is the summary data and the second is the sample.
Rate/Raw controls the display of data as either a "rate", expressed per second, or as the raw data. The default is to show metrics as a rate ("r"). Not all data is sensibly interpreted this way.
| Metric | Description |
| Hit Ratio | This is the ratio of "logical reads" to "operating system reads". Higher
values are generally a good thing because they mean less "physical" IO and
IO the root of most performance problems. This is, however, only a symptom
of problems. To find the root cause you must find the source of the IO or
the reason why logical requests are not being fulfilled from the -B cache. |
| Miss% | The inverse of Hit Ratio expressed as a percentage. In many ways the miss%
is a more helpful metric to look at. Relatively small (and meaningful)
changes in Hit Ratio are magnified and made more obvious in the miss ratio. |
| Hit% | The Hit Ratio expressed as a percentage. A false sense of well-being is
often felt by people when they see numbers like "95%" -- it sounds good
but is actually pretty awful. |
| Log Reads | The number of "logical read" operations requested of the database. These
operations do not directly correspond to record reads. These are reads of
database blocks and include both index and data components. Typically there
will be approximately two logical reads per record read but fragmented
records and other conditions can cause that ratio to vary. YMMV.
These reads are from the database engine's point of view. Badly formed queries (lacking sufficient index criteria and requiring client side sorting and selection) that are resolved by the 4gl client show up here as a large number of logical reads even though only a few records are actually made available to application code. If you see a large number here and believe that your programs are using a much smaller number of records then you probably have an indexing or query coding problem that needs to be resolved. |
| OS Reads | This is what happens when a logical read request cannot be fulfilled by
referring to the -B buffer cache. A disk read will take place. Memory
references are measured in tens of nanoseconds (10^-9). Disk requests are
measured in milliseconds (10^-3). That means that a disk is *literally*
100,000 times slower than memory. Every OS read comes at the expense of a
hundred thousand or so potential logical reads (if it is satisfied
immediately -- if you have disk queues the effect is dramatically
multiplied.) You want OS reads to be very, very rare. This is why a hit
ratio of 95% sucks and why even "small" disk queues are a very bad thing. |
| Rec Reads | The number of record reads that have occurred. |
| Log/Rec | The ratio of logical reads to record reads. This should be generally close to "2" since a record read
requires the reading of the data block containing the record and at least one index block. Larger values
may indicate that your database has a lot of fragmented records and could potentially benefit from a dump and load. |
| Area Full | The number of storage areas that have exceeded 80% of their allocated storage and the percentage fill of the fullest of these areas. |
| Commits | The number of transactions that have been committed to the database. |
| Latch Waits | Latches are data structures which are used to regulate access to shared
memory. (Another term for latches is "MUTEX".) A latch must be obtained
any time a process needs to access a shared data structure EVEN TO READ
IT. This is required in order to ensure data integrity.
If a process cannot obtain a latch it will "spin" attempting to get the latch (the number of spins is controlled by the -spin startup parameter. If the process fails to get the latch by spinning it will then wait. When the number of latch waits starts to climb you may be experiencing "latch contention". This means that your database is constrained by the speed of a single CPU (latches represent a single thread of execution). If this is the case then you must either upgrade your hardware or modify your code to request fewer latches (remember that, among other things, latches are obtained to READ blocks and that large logical read rates will result in large numbers of latch requests...) Use the Latch Wait module to further explore the source of latch waits. |
| Tot/Mod Bufs | Total Buffers is -B + 2. Modified Buffers is the number of buffers that
have been updated and which need to be written back to disk. |
| Evict Bufs | This is the number of buffers which were evicted from the buffer pool
in order to make room for a buffer being read. A Least Recently Used
algorithm is used to select buffers for eviction. |
| Lock Table | The size of the Record Lock Table as defined by the -L startup parameter
and the current number of entries in use. The Lock Table is shared by all
users. In general this value should be some relatively small number
multiplied by the number of connections that will concurrently need to
obtain locks. |
| LkHWM | The High Water Mark of the Lock Table -- the largest number of locks that
have been used since the database started. If this value is consistently
near the size of the Lock Table then you might want to consider increasing
it. |
| Old/Curr BI | The oldest BI cluster number and the current BI cluster number. If the
difference between these is large then you have active transactions that
span large periods of time -- this is bad in itself. You may also be
experiencing unusual amounts of BI file growth since BI clusters cannot
be reused while the still contain an active transaction. Use the "OpenTRX", "ActiveTRX" and "Blocked" modules to further examine possible sources of problems with BI clusters. If there are no active transactions the cluster numbers will show as 0. The numbers here do not directly correspond to checkpoint numbers by default. BI clusters numbers are stored as sequence since the last "truncate BI" was executed and can be aligned to checkpoint numbers but that requires a database transaction to accomplish. There is experimental code that can be enabled to do this in lib/protop.i but these values convey the important data well enough. |
| After Image | The status of After Imaging.
If AI is enabled this will show the AI extent that is currently in use. If AI is not enabled then this will show "Disabled". Running a production database without after imaging is foolhardy. If you do not have after imaging enabled your data (and your job) is at risk. You should enable after imaging on all production databases if their data is at all important. |
| Sessions | The total number of database connections. This is not the sum of the
columns below because some connection types are counted more than once.
The Connection Summary screen has a more detailed analysis. |
| Local | The current number of "Self-Service" or "Shared Memory" database
connections. |
| Remote | The current number of "Remote" or "Client Server" database connections.
These are connections that use the -S connection parameter. |
| Batch | Local or Remote connections that are using the -b client startup parameter. |
| Server | The number of servers that are running for remote clients to connect to.
More information about remote connections and the servers that they attach to can be found in the "Servers", "ServerIO" and "Server Details" modules. |
| Other | Other connections. This includes page writers (AIW, APW & BIW) the watchdog
process (WDOG), app servers and anything else that hasn't already been
counted. |
| TRX | The number of connections with OPEN transactions. This includes both ACTIVE
and ALLOCATED transactions.
Check the "OpenTRX" and "ActiveTRX" modules for a more detailed look at Transaction activity. |
| Blocked | Sessions which are waiting for a resource. Generally this is a record lock
although other resources may be unavailable in some circumstances. The
"Blocked" module provides details regarding which session is waiting for
what and, in the case of record locks, who currently has the record and who
else is in line for it.
If other resource waits appear on the "Blocked" screen the "Resource Waits" module may have additional information. The code shown under "Notes" on the "Blocked" screen is a hyper abbreviated version of the resource name shown by the "Resource Waits" module. Seeing anything other than a record lock wait on the "Blocked" screen is highly unusual and should be pursued. |
Top
ProTop Commands & Navigation
Commands are case-sensitive. Type "q" to exit help screens.
^d, q Quit ProTop.
? Startup command help.
h Obtain this help message.
H Context sensitive help.
b Select sort criteria.
c Connect a database (dialog box).
d Change the currently displaying windows.
<Enter> or <Space> to select an item.
<F1> or ^X to save changes.
<F4> or ^E to exit without saving changes.
e Examine an item.
i Adjust the monitoring interval.
p Set current page#.
r set "rate" mode for statistics (per second).
R set "Raw" mode for statistics (number per interval).
s set "sample" mode for statistics (interval = sample).
S set "Summary" mode for statistics (interval = cumulative).
t Comma delimited list of entities to track.
w Reload loadable modules.
x List of entities to exclude.
z Re-initialize (zero) the counters.
+ Increment page#.
- Decrement page#.
Top
Active Transactions
Active Transactions displays transactions except for those whose status is "Allocated". Allocated transactions may not turn into "real" transactions if no data is actually updated and are, therefore, considered a nuisance by some.
Active Transactions -- (Does NOT include "Allocated TRX") Usr Name TRX Num BI Clstr Start Trx Stat Duration Wait ----- ------------ ---------- -------- -------- -------- -------- -------------- 321 julia 706184385 303 17:03:48 ACTIVE 00:02:02 REC 20626853 344 peter 706184386 303 17:03:48 ACTIVE 00:02:02 REC 20626852 326 emily 706184387 303 17:03:48 ACTIVE 00:02:02 REC 20626852 447 tucker 706257644 303 17:05:50 ACTIVE 00:00:00 -- 21775 447 tiger 706257645 303 17:05:50 ACTIVE 00:00:00 -- 21775 401 tom 706471181 303 17:05:50 ACTIVE 00:00:00 -- 1 1278 jami 706471188 303 17:05:50 ACTIVE 00:00:00 -- 2 976 granite 725600928 303 17:05:50 ACTIVE 00:00:00 BIWR 42341
The following fields are displayed for each active transaction:
| Metric | Description |
| Usr | The Usr# of the connection that owns the transaction. |
| Name | The User Name associated with the connection. |
| TRX Num | The unique id of this transaction. |
| BI Clstr | The BI Cluster where this transaction has been opened. BI Clusters are
numbered sequentially since the last "truncate bi" operation.
If the difference between the oldest BI cluster number and the current BI cluster number is large then you have active transactions that span large periods of time -- this is bad in itself. You may also be experiencing unusual amounts of BI file growth since BI clusters cannot be reused while they still contain an active transaction. The numbers here do not directly correspond to checkpoint numbers by default. BI clusters numbers are stored as sequence since the last "truncate BI" was executed and can be aligned to checkpoint numbers but that requires a database transaction to accomplish. There is experimental code that can be enabled to do this in lib/protop.i but these values convey the important data well enough. |
| Start | The time when this transaction became active. (It may be a different day! If so it isn't displayed.) |
| Trx Stat | The status of this transaction. |
| Duration | How long has this transaction been active? |
| Wait | What, if anything, are we waiting for? Record locks are typical. They are indicated by "REC" followed by the RECID of the record. The "Blocked" screen gives more information about such a situation such as the table name and the list of users holding the record or (also) waiting for a lock. |
Top
After Imaging Status
Displays status information about AI extents. AI extents must have "read" permission at the OS level in order for the "Note" field to work.
After Imaging Status Area Extent Blocks Hi Water Free %Used Seq# Note ---- ------------------ -------- -------- -------- --------- -------- ---------- 79 s2k.a1 15 0 15 0.00% 0 Empty 80 s2k.a2 3983 0 3983 0.00% 6994 Full 81 s2k.a3 79 20 59 25.32% 6995 Busy 82 s2k.a4 15 0 15 0.00% 0 Empty 83 s2k.a5 15 0 15 0.00% 0 Empty 84 s2k.a6 15 0 15 0.00% 0 Empty 85 s2k.a7 15 0 15 0.00% 0 Empty 86 s2k.a8 15 0 15 0.00% 0 Empty
| Metric | Description |
| Area | The Area number. Each AI Extent is a separate Storage Area. |
| Extent | The file name of the extent. |
| Blocks | The number of blocks allocated to this extent. |
| Hi Water | The extents high water mark. |
| Free | The number of blocks free for AI notes. |
| %Used | The percentage of blocks in use. |
| Seq# | The sequence number of this extent since after-imaging was enabled. |
| Note | The status of the extent. Empty, Full & Busy are the valid values. |
Top
Storage Area Details
Details of the Storage Area specified by examine-item (the "e" command). The selected area, it's tables and indexes are shown.
Area Details for Cust_Index Area Area Name Blocks Hi Water Free %Used RPB Note ---- ------------------------- -------- -------- -------- ------- --- ---------- 10 Cust_Index 350 71 279 20.29% 32 i(5) Table Details for Cust_Index Tbl# Table Name Create Read Update Delete ---- -------------------------- --------- --------- --------- --------- Index Details for Cust_Index Idx# Index Name Create Read Split Delete BlkDel ---- ----------------------- -- --------- --------- --------- --------- -------- 12 CustNum PU 0 0 0 0 0 13 Comments 0 0 0 0 0 14 CountryPost 0 0 0 0 0 15 Name 0 0 0 0 0 16 SalesRep 0 0 0 0 0
The first section shows a summary of statistics about the selected Storage Area.
| Metric | Description |
| Area | The Area number. (Each AI Extent is a separate Storage Area.) |
| Area Name | The descriptive name of the Storage Area. |
| Blocks | The number of blocks allocated to this extent. |
| Hi Water | The extent high water mark. |
| Free | The number of blocks free for AI notes. |
| %Used | The percentage of blocks in use. |
| RPB | The number of Rows Per Block for the area. |
| Note | The number of tables t(#) & indexes i(#) assigned to the area. If the schema area has tables or indexes assigned to it that will be indicated via "***". |
The second section shows the tables (if any) that are assigned to the selected area. Tables that do not have _TableStat data available are indicated with a leading"*". (This may be because -tablebase or -tablerangesize need adjustment.)
| Metric | Description |
| Tbl# | The table id#. |
| Table Name | The table name. |
| Create | The number of record CREATE operations for this table. |
| Read | The number of record READ operations for this table. |
| Update | The number of record UPDATE operations for this table. |
| Delete | The number of record DELETE operations for this table. |
The third section shows the indexes (if any) that are assigned to the selected area. Indexes that do not have _IndexStat data available are indicated with a leading"*". (This may be because -indexbase or -indexrangesize need adjustment.)
| Metric | Description |
| Idx# | The index id#. |
| Index Name | The index name. |
| Create | The number of index CREATE operations for this index. |
| Read | The number of index READ operations for this index. |
| Split | The number of index SPLIT operations for this index. |
| Delete | The number of index DELETE operations for this index. |
| BlkDel | The number of index BLOCK DELETE operations for this index. |
Top
Storage Area Status
Status of Storage Areas.
Area Statistics A# Area Name Alloc Var Hi Water Free %Used Note --- -------------------- --------- --------- --------- --------- ------- ------- 68 order_idx 16 1998 1927 87 12044% i(3) 67 order 256 14670 14860 66 5805% t(1) 6 Schema Area 256 1454 1391 319 543% i(25) * 3 Primary Recovery Are 32000 13070 45056 14 141% 13 customer 512000 55565 567515 50 111% t(15) 92 After Image Area 3 0 5199 5191 8 100% Busy 49 order-line 32000 2 25164 6838 79% t(1) 61 inventory 128000 2 94897 33105 74% t(1) 55 discount 1024000 0 755885 268114 74% t(1) 57 employee 2048000 0 1442919 605076 70% t(1)
| Metric | Description |
| Area | The Area number. (Each AI Extent is a separate Storage Area.) |
| Area Name | The descriptive name of the Storage Area. |
| Alloc | The number of blocks allocated to this Storage Area. |
| Var | The number of blocks in a variable extent (if there is one) that are being used by the Storage Area. |
| Hi Water | The Storage Area's high water mark. |
| Free | The number of free blocks free remaining in the Storage Area. |
| %Used | The percentage of allocated blocks in that are use. Percentages in excess of 100% indicate that all of the allocated blocks have been used and that a variable length extent is now growing. |
| Note | The number of tables t(#) & indexes i(#) assigned to the area. If the schema area has tables or indexes assigned to it that will be indicated via "***". |
Top
BigB GuessTimator
Based on the calculation in this thread:
http://www.peg.com/lists/dba/history/200301/msg00509.html
which originates in a 1998 posting (by me) referring to some interesting research published by IBM. The formula used here is the one derived by Tim Casey:
m2 = m1 * sqrt( b1 / b2 )
This results in a simple calculation of the expected impact on OS reads which is generally the ultimate goal of tuning -B.
This is not an exact calculation -- there should be a locally calibrated constant applied to ( b1 / b2 ). The value is probably between 0.5 & 1.5 but these results are, IMHO, close enough to give an idea of what to expect plus or minus a bit (maybe 25%).
It should also be noted that as increases in -B reduce OS reads you can expect to see a possibly significant increase in logical reads since less time will be spent waiting for OS reads -- this will impact the OS reads in a recursive manner.
You'll get better results if you sample for a longer period. 10 second samples (for instance) can have quite a lot of variation from sample to sample. I'd try at least 60 seconds for starters.
Use the "e" command to enter a user defined exploratory value for -B.
Values of -B that would result in the entire database fitting into memory will return a miss ratio of 0% and the hit ratio will be shown as 99999999.
If the database that is being monitored has a miss ratio of 0% then it is not possible to estimate the impact of changes to -B.
Results will vary more with small databases than with large databases.
Big B GuessTimator
Pct Big B % db Size Hit:1 Miss% Hit% OS Reads
------- ----------- ----------- -------- -------- -------- --------
10% 12500 0.147% 9 11.103% 88.897% 37973
25% 31251 0.369% 14 7.022% 92.978% 24016
50% 62501 0.737% 20 4.965% 95.035% 16982
100% 125002 1.475% 28 3.511% 96.489% 12008 <== Current
150% 187503 2.212% 35 2.867% 97.133% 9804
200% 250004 2.949% 40 2.483% 97.517% 8491
400% 500008 5.899% 57 1.756% 98.244% 6004
800% 1000016 11.798% 81 1.241% 98.759% 4245
1000% 1250020 14.747% 90 1.110% 98.890% 3797
2000% 2500040 29.495% 127 0.785% 99.215% 2685
5000% 6250100 73.737% 201 0.497% 99.503% 1698
10000% 12500200 147.474% 99999999 0.000% 100.000% 0
The following fields are displayed:
| Metric | Description |
| Pct | A percentage of the currently executing Big B parameter. 100% is the current state.
A range of both increases and decreases is shown in order to demonstrate the expected results of making changes to the Big B startup parameter. |
| Big B | The value of Big B need to attain the indicated percentage level. |
| % db Size | The rough portion of the database that that setting represents. |
| Hit:1 | The "hit ratio". |
| Miss% | The percentage of reads that would be cache misses. |
| Hit% | The percentage of reads that would be expected to be cache hits. (This metric is often loosely referred to as the hit ratio.) |
| OS Reads | The number of disk reads that your disk subsystem would need to be able to handle at that setting. |
Top
Blocked Clients
Sessions which are waiting for a resource. Generally this is a record lock although other resources may be unavailable in some circumstances. The "Blocked" module provides details regarding which session is waiting for what and, in the case of record locks, who currently has the record and who else is in line for it.
If other resource waits appear on the "Blocked" screen the "Resource Waits" module may have additional information. The code shown under "Notes" on the "Blocked" screen is a hyper abbreviated version of the resource name shown by the "Resource Waits" module. Seeing anything other than a record lock wait on the "Blocked" screen is highly unusual and should be pursued.
Blocked Sessions Usr Name Waiting Note ----- ------------ -------- ---------------------------------------------------- 332 tom 00:00:53 BKSH:43392: 326 jami 00:00:05 BKSH:82564928: 321 julia 00:00:00 BKSH:83524928: 344 peter 00:00:00 BKSH:90044096: 326 emily 00:00:26 REC XQH:193:[order] 321 tiger 00:00:10 REC XQH:193:[order] 326 tucker 00:00:48 REC XQH:20626852:[customer] 344 granite 00:00:16 REC XQH:20626852:[customer]
| Metric | Description |
| Usr | The Usr# for the blocked connection. |
| Name | The User Name associated with the connection. |
| Waiting | How long has this transaction been waiting to complete? |
| Note | The reason that the session is blocked. The most frequent reason is a
record lock. This will be displayed as "REC" followed by flags, the RECID
of the record, the table name of the record and a list of users queued
for that record (the list may be longer than can be shown on the screen.)
Possible values of the REC flags are:
Other blocked states (such as BKSH and RGET) may be shown but are relatively rare. The "Resource Waits" screen has additional data about these waits and the frequency of requests and waits. |
Top
Checkpoint History
Shows the 8 most recent checkpoints.
Checkpoints occur as BI clusters fill. When a BI cluster is full it must be flushed to disk before the next cluster is filled. It helps to have a reasonable amount of time between checkpoints to allow the Asynchronous Page Writers (APWs) time to accomplish this task. Rapid fire checkpoints (spaced less than 5 to 15 minutes apart) indicate that your BI cluster size is too small. Sudden business growth or unusual processes could potentially overwhelm your page writers causing buffer flushes and performance problems.
If you have a WORKGROUP database rather than an Enterprise database it is better to have many short checkpoints than fewer long checkpoints. This is because without page writers you're better off spreading the IO hit evenly. With large checkpoints WORKGROUP users will periodically grind to long halts as checkpoints occur.
Checkpoint Data
Checkpoints: 35
Buffers Flushed: 1094
-
ChkPt Start End Dirty ChkPtQ Scan APW Q Flushed
------ -------- -------- -------- -------- -------- -------- --------
1 09:10:47 8368 810 436 11864 0
2 09:03:01 09:10:33 8723 4817 924 12757 0
3 08:53:08 09:02:38 7393 1247 1479 10046 0
4 08:40:55 08:52:12 6421 2747 1612 11926 0
5 08:28:53 08:40:14 9328 999 1599 18947 0
6 08:12:45 08:28:11 13555 2524 1994 14739 0
7 08:00:34 08:11:54 19695 2271 2332 21704 0
8 07:56:04 08:00:03 20428 20204 1722 598 0
The following fields are displayed:
| Metric | Description |
| ChkPt | Checkpoint history number. Checkpoint #1 is the checkpoint that is currently in process - thus it hasn't ended yet. |
| Start | When did processing of this checkpoint start? |
| End | When did processing of this checkpoint end? |
| Dirty | The number of modified buffers. |
| ChkPtQ | The number of buffers written from the checkpoint queue. |
| Scan | The number of buffers written while scanning. |
| APW Q | The number of buffers written from the APW queue. |
| Flushed | The number of buffers flushed at the end of the checkpoint. If this is consistently
a non-zero value you need to increase the number of APWs that are running.
Flushed buffers occur when a "lazy" checkpoint has not finished writing dirty buffers before the next bi cluster fills. Every user who is updating the database must stop and wait for these buffers to be flushed before they can continue. These writes are synchronous and the "freeze" is very noticeable. You don't want this to happen. (Unless you are running a Workgroup database -- in that case you cannot avoid the flushes and you want to do them very frequently in order to minimize the impact of any single checkpoint.) |
Top
Configuration and Startup
Display key start parameters and configuration settings.
Config and Startup
------------------------------
Progress Version: 10.1
DB Block Size: 8192
BI Block Size: 16384
BI Cluster Size: 65536
AI Block Size: 16384
-spin: 50000
-directio: Yes
-i: Reliable
-r: Buffered
-n: 5000
Top
Connection Summary
Connection Summary
Session Type Users Log Rd OS Rd OS Wr Hit% Trx Blkd
------------- ----- --------- --------- ------- -------- ------ -----
All Sessions: 2441 233284 3548 5 98.48% 28 0
GUI Users: 1053 0 0 0 0.00% 1 0
ChUI Users: 8 71 0 0 100.00% 1 0
Batch: 35 208092 3901 0 98.13% 25 0
App Servers: 1052 0 0 0 0.00% 1 0
4GL Servers: 260 0 0 0 0.00% 0 0
SQL Servers: 0 0 0 0 0.00% 0 0
Helpers: 14 0 0 5 100.00% 0 0
Other: 19 0 0 0 0.00% 0 0
The following fields are displayed:
| Metric | Description |
| Session Type | A categorization of sessions. |
| Users | The number of users (or sessions) that fall into that category. |
| Log Rd | The number of database logical reads that this class of user has requested. |
| OS Rd | The number of times that logical reads initiated by this class of user have resulted in an OS read() operation. |
| OS Wr | The number of OS write() operations that these processes have performed. |
| Hit% | The percentage of times that db blocks were found for these processes in the
buffer cache instead of being read from disk. For the "Helper" category the hit% is the % of OS Writes that the helpers performed. |
| TRX | The number of these sessions that have a transaction open. |
| Blkd | The number of these sessions that are blocked on a resource. See the Blocked screen for details. |
Top
Disk Free
Show the amount of filesystem free space.
Free Disk Space Mount Point FS Size FS Free Used% Growth Alert ------------------------------ ---------- ---------- ------- ------ ----- / 262144 202836 22.62% 0 /home 393216 59968 84.75% 0 ***** /bi 3014656 2292716 23.95% 0 /usr 3932160 812364 79.34% 0 /app 20840448 6435940 69.12% 1024 /data 28835840 17695076 38.64% 0 /ai 52297728 15665300 70.05% 768 /aisave 52297728 15665300 70.05% -256 /backup 62521344 11148720 82.17% 0
The following fields are displayed:
| Metric | Description |
| Mount Point | The name of the mounted filesystem. |
| FS Size | The configured size of the filesystem in 1K blocks. |
| FS Free | The number of free blocks. |
| Used% | How full is the filesystem? |
| Growth | How many blocks have been added or subtracted since the last interval? |
| Alert | If the filesystem is more than 80% full then "*****" will display. |
Top
File IO
IO Operations to database extents.
Database File IO Id Extent Name Mode Blksz Size Read Write Extend ---- ------------------------- -------- ----- ---------- ------ ------ ------ 63 s2k_29.d1 F UNBUF 8192 2048000 11828 0 0 64 s2k_29.d2 F UNBUF 8192 2048000 7790 0 0 124 s2k_55.d2 F UNBUF 8192 2048000 432 0 0 125 s2k_55.d3 F UNBUF 8192 2048000 367 8 0 123 s2k_55.d1 F UNBUF 8192 2048000 220 0 0 67 s2k_30.d1 F UNBUF 8192 2048000 106 0 0 57 s2k_26.d1 F UNBUF 8192 1024000 26 2 0 128 s2k_56.d1 F UNBUF 8192 2048000 19 1 0 54 s2k_25.d2 F UNBUF 8192 2048000 17 1 0 119 s2k_53.d1 F UNBUF 8192 1024000 15 2 0 111 s2k_49.d1 F UNBUF 8192 256000 14 0 0 135 s2k_57.d6 F UNBUF 8192 2048000 12 0 0 140 s2k_58.d2 F UNBUF 8192 1024000 11 1 0 121 s2k_54.d1 F UNBUF 8192 256000 7 0 0 139 s2k_58.d1 F UNBUF 8192 1024000 6 0 0 134 s2k_57.d5 F UNBUF 8192 2048000 5 0 0 69 s2k_31.d1 F UNBUF 8192 128000 4 0 0 73 s2k_33.d1 F UNBUF 8192 128000 3 0 0 3 s2k.b2 V UNBUF 16384 0 0 0 0
| Metric | Description |
| Id | The extent id number. |
| Extent Name | The file name of the extent. |
| Mode | The "mode" in which the file is opened. Possible values are:
|
| BlkSz | The Block size for the extent. This potentially varies between data, before-image and after-image extents. Values are expressed in bytes. |
| Reads | The number of read operations. |
| Writes | The number of write operations. |
| Extend | The number of times that a variable extent has been expanded. |
Top
Helper Processes
Displays the activities of APW, AIW and BIW processes.
Helper Processes
Helper Metric BIW BIW% AIW AIW%
-------------------- ----------- -------- ----------- --------
Notes Written: 1078.17 1078.00
BI/AI Writes: 11.33 61.76% 9.00 98.15%
BIW/AIW Writes: 7.00 8.83
Partial Buff Writes: 3.17 9.00
Busy Buffer Waits: 1.50 0.00
Empty Buffer Waits: 0.00 0.00
APW APW%
-------------------- ----------- -------- ----------- --------
DB Writes: 15.00
APW Writes: 15.00 100.00%
Scan Cycles: 0.00
Buffers Scanned: 194.33 -pwsdelay 1
APW Scan Writes: 3.83 -pwqdelay 100
APW Queue Writes: 11.33 -pwscan 208
Chkpt Queue Writes: 0.00 -pwwmax 25
Flush at Checkpoint: 14656
Top
Hit Ratio Bar Chart
An "ASCII-Art" bar chart of Hit Ratio variation over time. The most current values are to the left. The oldest observed value is to the right.
Hit Ratio Bar Chart 100.00 99.80 @ @ @@@@@@@@@ 99.60 @@@@ @@@@@@@@@@@@ 99.40 @@@@@@@@@@@@@@@@@@@ 99.20 @@@@@@@@@@@@@@@@@@@@ 99.00 @ @@@@@@@@@@@@@@@@@@@@@@@@ 98.80 @ @@@@@@@@@@@@@@@@@@@@@@@@ 98.60 @@ @@@@@@@@@@@@@@@@@@@@@@@@ 98.40 @@@@@@@@@@@@@@@@@@@@@@@@@@@@ 98.20 @@@@@@@@@@@@@@@@@@@@@@@@@@@@ 98.00 @@@@@@@@@@@@@@@@@@@@@@@@@@@@
Top
Hit Ratio History
Show the history of variation in the Hit Ratio from sample to sample.
Hit Ratio History
Seq# Log Rd OS Rd Hit%
------ ---------- ---------- -------
12 190104 14035 92.62%
11 142197 13616 90.42%
10 93480 1134 98.79%
9 82286 777 99.06%
8 135140 873 99.35%
7 99045 886 99.11%
6 171185 2181 98.73%
5 202032 3897 98.07%
4 186609 755 99.60%
3 93844 816 99.13%
The following fields are displayed:
| Metric | Description |
| Seq# | The snapshot sequence#. |
| Log Rd | The number of database logical reads that this class of user has requested. |
| OS Rd | The number of times that logical reads initiated by this class of user have resulted in an OS read() operation. |
| OS Wr | The number of OS write() operations that these processes have performed. |
| Hit% | The percentage of times that db blocks were found for these processes in the buffer cache instead of being read from disk. |
Top
Index Statistics
Indexes that do not have _IndexStat data available are indicated with a leading"*". (This may be because -indexbase or -indexrangesize need adjustment.)
Index Statistics Idx# Index Name Create Read Split Del BlkD ---- ---------------------------------------- -- ------ ------- ----- ----- ---- 928 Invoice.InvoiceNum 3 28576 0 4 0 543 Invoice.CustNum PU 1 14580 0 0 0 459 Invoice.InvoiceDate 0 10364 0 0 0 456 Invoice.OrderNum 0 5492 0 0 0 522 Customer.CustNum 3 3459 0 1 0 98 Customer.Comments 0 1370 0 0 0 885 Customer.CountryPost PU 0 715 0 0 0 1033 Customer.Name 0 684 0 0 0 519 Customer.SalesRep 1 571 0 1 0 880 Item.ItemNum PU 1 415 0 1 0 1280 Item.CatDescription U 0 388 0 0 0 902 Item.Category2ItemName P 0 364 0 0 0 516 Item.CategoryItemName PU 0 328 0 0 0 924 Item.ItemName PU 1 307 0 1 0 890 OrderLine.orderline PU 0 305 0 0 0 1328 OrderLine.itemnum 74 302 0 74 0 959 OrderLine.OrderLineStatus PU 0 237 0 0 0 92 Salesrep.SalesRep PU 0 218 0 0 0
| Metric | Description |
| Idx# | The index id#. |
| Index Name | The index name. |
| Create | The number of index CREATE operations for this index. |
| Read | The number of index READ operations for this index. |
| Split | The number of index SPLIT operations for this index. |
| Delete | The number of index DELETE operations for this index. |
| BlkDel | The number of index BLOCK DELETE operations for this index. |
Top
Latch Requests and Waits
Latches are data structures which are used to regulate access to shared memory. (Another term for latches is "MUTEX".) A latch must be obtained any time a process needs to access a shared data structure EVEN TO READ IT. This is required in order to ensure data integrity.
If a process cannot obtain a latch it will "spin" attempting to get the latch (the number of spins is controlled by the -spin startup parameter. If the process fails to get the latch by spinning it will then wait. When the number of latch waits starts to climb you may be experiencing "latch contention". This means that your database is constrained by the speed of a single CPU (latches represent a single thread of execution).
If this is the case then you must either upgrade your hardware or modify your code to request fewer latches (remember that, among other things, latches are obtained to READ blocks and that large logical read rates will result in large numbers of latch requests...) Use the Latch Wait module to further explore the source of latch waits.
Latches are very short duration internal locks. Very tight and highly optimized sections of code are executed while a latch is held. No IO takes place while a latch is held. Latch duration can typically be measured in microseconds. Latches do not directly correspond to 4gl code.
Latch Waits Id Latch Requests Waits Lock% --- -------------------- ---------- ---------- ------- 17 MTL_BHT 62474 0 100.00% 21 MTL_LRU 62460 0 100.00% 15 MTL_LKF 60682 0 100.00% 4 MTL_OM 30990 0 100.00% 5 MTL_BIB 167 0 100.00% 20 MTL_CPQ 94 0 100.00% 2 MTL_MTX 73 0 99.75% 9 MTL_TXT 63 0 100.00% 12 MTL_AIB 56 0 100.00% 13 MTL_TXQ 33 0 100.00% 6 MTL_SCC 30 0 100.00% 7 MTL_LKP 4 0 100.00% 18 MTL_PWQ 1 0 100.00% 8 MTL_GST 0 0 0.00% 11 MTL_SEQ 0 0 0.00% 16 MTL_BFP 0 0 0.00% 3 MTL_USR 0 0 0.00% 14 MTL_BIW 0 0 0.00%
| Metric | Description |
| Id | The numeric id of this latch. |
| Latch | The name of the latch. The secret decoder ring is only available at 4gl fan club meetings. |
| Requests | The number of times this latch was requested. |
| Waits | The number of times someone had to wait for the latch. |
| Lock% | The percentage of successful requests. |
Top
Network Statistics
Network Interface Statistics Interface Received Rcvd - Err Transmitted Trans - Err -------------------- ----------- ----------- ----------- ----------- eth0 535 0 55 0 lo 0 0 0 0
The following fields are displayed:
| Metric | Description |
| Interface | The name of the network interface. |
| Received | The number of packets received. |
| Rcvd - Err | The number of packets received with errors. |
| Transmitted | The number of packets transmitted. |
| Trans - Err | The number of errors transmitting packets. |
Top
Open Transactions
Open Transactions displays all transactions -- including those whose status is "Allocated". Allocated transactions may not turn into "real" transactions if no data is actually updated and are considered a nuisance by some.
Open Transactions Usr Name TRX Num BI Clstr Start Trx Stat Duration Wait ----- ------------ ---------- -------- -------- -------- -------- -------------- 346 762056563 - ALLOCATE 00:00:00 -- 9600 338 762056636 - ALLOCATE 00:00:00 -- 9600 336 762056798 - ALLOCATE 00:00:00 -- 256 340 762056800 - ALLOCATE 00:00:00 -- 9600 341 762056807 - ALLOCATE 00:00:00 -- 9600 342 762056828 - ALLOCATE 00:00:00 -- 9600 316 762056834 - ALLOCATE 00:00:00 -- 9600 332 762056840 - ALLOCATE 00:00:00 -- 9600 335 762056844 - ALLOCATE 00:00:00 -- 9600 326 762056848 - ALLOCATE 00:00:00 -- 3 329 762056853 - ALLOCATE 00:00:00 -- 9600 343 762056857 - ALLOCATE 00:00:00 -- 9600
The following fields are displayed for each transaction:
| Metric | Description |
| Usr | The Usr# of the connection that owns the transaction. |
| Name | The User Name associated with the connection. |
| TRX Num | The unique id of this transaction. |
| BI Clstr | The BI Cluster where this transaction has been opened. BI Clusters are
numbered sequentially since the last "truncate bi" operation.
If the difference between the oldest BI cluster number and the current BI cluster number is large then you have active transactions that span large periods of time -- this is bad in itself. You may also be experiencing unusual amounts of BI file growth since BI clusters cannot be reused while the still contain an active transaction. If there are no active transitions the cluster numbers will show as 0. The numbers here do not directly correspond to checkpoint numbers by default. BI clusters numbers are stored as sequence since the last "truncate BI" was executed and can be aligned to checkpoint numbers but that requires a database transaction to accomplish. There is experimental code that can be enabled to do this in lib/protop.i but these values convey the important data well enough. |
| Start | The time when this transaction became active. (It may be a different day! If so it isn't displayed.) |
| Trx Stat | The status of this transaction. |
| Duration | How long has this transaction been active? |
| Wait | What, if anything, are we waiting for? Record locks are typical. They are indicated by "REC" followed by the RECID of the record. The "Blocked" screen gives more information about such a situation. |
Top
Record Locks
This screen shows information about record locks. BE CAREFUL!!! it can be very slow on a large production system and there may be a performance impact on users from running this screen! This is probably most useful in development environments.
Record Locks Usr Name Recid Duration Table Type Chain Flags ----- ------------ ---------- -------- -------------------- ---- -------- ----- 393 tom 25830872 00:00:00 order REC 1206 S 929 jami 25830873 00:00:00 order REC 1207 S 1401 julia 25830874 00:00:00 order REC 1208 S 1414 peter 25830871 00:00:00 order REC 1205 S 4153 emily 61829 00:00:00 holiday REC 2368 S 4686 tiger 6058307 00:00:00 warehouse REC 4932 X L 4686 granite 20560335 00:00:00 inventory REC 6222 X L 4686 tucker 20625600 00:00:00 inventory REC 1675 X L 4153 lauria 61829 00:00:20 control REC 2368 S 393 carol 25830872 00:00:20 order REC 1206 S 1401 don 25830874 00:00:20 order REC 1208 S 929 tom 25830873 00:00:20 order REC 1207 S 1414 mike 25830871 00:00:20 order REC 1205 S 431 tim 31297274 00:00:00 order-line REC 2522 X L 431 steph 31297275 00:00:00 order-line REC 2523 X L 431 steve 48376277 00:00:00 employee REC 7405 X 431 stacey 30982808 00:00:00 order-line REC 7192 X L 431 tom 0 00:00:00 order-line TAB 10495 IX L 431 tucker 30982814 00:00:00 order-line REC 7198 X L 323 tiger 48376523 00:00:00 employee REC 7651 S
The following fields are displayed:
| Metric | Description |
| Usr | The Progress usr# of the user holding the lock. |
| Name | The login name of that user. |
| Recid | The RECID of the locked record. |
| Duration | How long has the lock been held? |
| Table | What table does the record belong to? |
| Type | What type of lock is this?
|
| Chain | Lock chain id. |
| Flags |
Possible values of the flags are:
|
Top
Resource Requests and Waits
Resources are internal locks. Resource lock duration can range from milliseconds to minutes, hours or days (think record locks). Resources, like latches, do not directly correspond to 4gl code although some are more directly related than others (again, think record locks).
Resource Waits Id Resource Locks Waits %Lock --- -------------------- ---------- ---------- ------- 10 DB Buf S Lock 70656 0 100.00% 6 Record Get 35056 0 100.00% 2 Record Lock 96 0 100.00% 5 DB Buf I Lock 84 0 99.88% 19 TXE Share Lock 56 0 100.00% 11 DB Buf X Lock 34 0 99.70% 20 TXE Update Lock 12 0 100.00% 21 TXE Commit Lock 10 0 100.00% 7 DB Buf Read 9 0 100.00% 8 DB Buf Write 4 0 100.00% 4 Trans Commit 4 0 100.00% 15 BI Buf Write 2 0 93.33% 17 AI Buf Write 1 0 100.00% 3 Schema Lock 0 0 0.00% 1 Shared Memory 0 0 0.00%
| Metric | Description |
| Id | The numeric id of this resource. |
| Resource | The name of the resource. The secret decoder ring is only available at 4gl fan club meetings. (It is, however, bulkier than that latch decoder ring...) |
| Requests | The number of times this resource was requested. |
| Waits | The number of times someone had to wait for the resource. |
| Lock% | The percentage of successful requests. |
Top
Server Details
The first section shows both the sample and summary views of statistics for the selected server.
Server Details
Srv Type Port Con Max Msg Recv Msg Sent Rec Recv Rec Sent Qry Sent TimeSlice
---- ----- ----- --- --- -------- -------- -------- -------- -------- ---------
155 Auto 1181 2 25
Cumulative: 0 0 0 0 0 0
Interval: 4 2 0 1 1 0
Users for Server 155
Usr Name Flags PID DB Access OS Reads OS Writes Hit%
----- --------------- ----- -------- ---------- ---------- ---------- -------
4535 tucker R 11412 8 0 0 98.68%
4533 tiger R 13584 0 0 0 0.00%
| Metric | Description |
| Srv | Server Id. |
| Type | What type of server is this? Possible values include:
|
| Port | TCP/IP Port number. The broker uses the port specified by -S. Other servers get an automatically assigned port number. |
| Con | Current number of connections to this server. |
| Max | The maximum number of connections that this server will permit (-Ma). |
| Msg Recv | Progress messages received by this server. (See -Mm documentation.) |
| Msg Sent | Progress messages sent by this server. (See -Mm documentation.) |
| Rec Recv | Records received from clients of this server. |
| Rec Sent | Records sent to clients of this server. |
| Qry Sent | Queries received by this server. |
| TimeSlice | The number of times that the server has interrupted work on a client query to check for other clients work. |
The second section shows User IO Statistics for the users connected to the selected server.
| Metric | Description |
| Usr | The Usr# for this connection. |
| Name | The User Name associated with this connection. |
| Flags | Connection type and status flags.
|
| PID | Operating system Process ID. |
| DB Access | The number of database block accesses that this user has requested. |
| OS Reads | The number of times that a database block accesses that this user has requested resulted in an OS read() operation. |
| OS Writes | The number of OS write() operations that this process has caused. |
| Hit% | The percentage of times that db blocks were found for this process in the buffer cache instead of being read from disk. |
Top
Server IO Requests
Server IO Srv Type Port Con Max DB Access OS Reads OS Writes Hit% ---- ----- ----- --- --- ---------- ---------- ---------- ------- 246 Auto 1274 2 25 91 0 0 99.94% 77 Auto 1103 2 25 47 0 0 100.00% 197 Auto 1223 1 25 14 0 0 100.00% 2 Auto 1026 5 25 12 0 0 100.00% 218 Auto 1245 2 25 11 0 0 99.52% 166 Auto 1192 1 25 10 0 0 100.00% 26 Auto 1050 1 25 10 0 0 100.00% 174 Auto 1200 3 25 9 0 0 100.00% 235 Auto 1263 3 25 9 0 0 100.00% 195 Auto 1221 1 25 8 0 0 100.00% 163 Auto 1189 1 25 8 0 0 100.00% 202 Auto 1228 2 25 7 0 0 100.00% 239 Auto 1267 3 25 7 0 0 100.00% 141 Auto 1167 2 25 6 0 0 100.00% 103 Auto 1129 1 25 5 0 0 100.00% 214 Auto 1241 3 25 5 0 0 100.00%
| Metric | Description |
| SRV | Server Id. |
| Type | What type of server is this? Possible values include:
|
| Port | TCP/IP Port number. The broker uses the port specified by -S. Other servers get an automatically assigned port number. |
| Con | Current number of connections to this server. |
| Max | The maximum number of connections that this server will permit (-Ma). |
| DB Access | The number of database block accesses that all users of this server have requested. |
| OS Reads | The number of times that database block accesses that users of this server have requested resulted in an OS read() operation. |
| OS Writes | The number of OS write() operations that users of this server have caused. |
| Hit% | The percentage of times that db blocks were found for the users connected to this server in the buffer cache instead of being read from disk. |
Top
Servers
Servers Srv Type Port Con Max MRecv MSent RRecv RSent QSent Slice ---- ----- ----- --- --- ------ ------ ------ ------ ------ ------ 183 Auto 1209 2 25 19 12 1 4 3 1 182 Auto 1208 1 25 13 9 0 3 2 1 150 Auto 1176 1 25 4 2 0 2 1 0 26 Auto 1050 1 25 4 3 0 0 2 6 195 Auto 1221 1 25 3 2 0 0 2 4 163 Auto 1189 1 25 3 2 0 1 1 2 2 Auto 1026 5 25 3 2 0 0 2 4 174 Auto 1200 3 25 3 2 0 0 1 3 126 Auto 1152 1 25 3 1 0 0 0 0 166 Auto 1192 1 25 2 2 0 0 1 3 235 Auto 1263 3 25 2 2 0 0 1 3 214 Auto 1241 3 25 2 1 0 0 1 3 173 Auto 1199 1 25 2 1 0 1 0 0 3 Auto 1027 4 25 2 1 0 0 1 1 141 Auto 1167 2 25 1 1 0 0 1 2 239 Auto 1267 3 25 1 1 0 0 1 3 202 Auto 1228 2 25 1 1 0 0 1 2 96 Auto 1122 2 25 1 1 0 0 0 0
| Metric | Description |
| Srv | Server Id. |
| Type | What type of server is this? Possible values include:
|
| Port | TCP/IP Port number. The broker uses the port specified by -S. Other servers get an automatically assigned port number. |
| Con | Current number of connections to this server. |
| Max | The maximum number of connections that this server will permit (-Ma). |
| Msg Recv | Progress messages received by this server. (See -Mm documentation.) |
| Msg Sent | Progress messages sent by this server. (See -Mm documentation.) |
| Rec Recv | Records received from clients of this server. |
| Rec Sent | Records sent to clients of this server. |
| Qry Sent | Queries received by this server. |
| TimeSlice | The number of times that the server has interrupted work on a client query to check for other clients work. |
Top
Table Details
The first section shows the selected table and both the sampled and summary data regarding the indicated IO operations. Tables that do not have _TableStat data available are indicated with a leading"*". (This may be because -tablebase or -tablerangesize need adjustment.)
Table Details for order
Tbl# Table Name Operation Cumulative Interval
---- -------------------- --------- ---------- ----------
178 order Create: 0 0
Read: 58 421
Update: 1 8
Delete: 0 0
Indexes for order
Idx# Index Name Create Read Split Delete BlkDel
---- ------------------------- -- -------- -------- -------- -------- --------
516 order-num PU 0 53 0 0 0
517 cust-num 1 47 0 0 0
518 cust-po 0 0 0 0 0
519 invoice-num 0 294 0 0 0
522 salesperson 2 813 0 0 0
523 store-num 1 22 0 0 0
| Metric | Description |
| Tbl# | The table id#. |
| Table Name | The table name. |
| Operation | Create The number of CREATE operations for this table. Read The number of READ operations for this table. Update The number of UPDATE operations for this table. Delete The number of DELETE operations for this table. |
| Cumulative | Summary statistics for the operation. Displayed as either a rate or as the raw metric depending on the state of the Rate/Raw command. |
| Interval | Sample statistics for the operation. Displayed as either a rate or as the raw metric depending on the state of the Rate/Raw command. |
The second section shows the indexes (if any) that are associated with the selected table. Indexes that do not have _IndexStat data available are indicated with a leading"*". (This may be because -indexbase or -indexrangesize need adjustment.) Data displayed is either sampled or the summary data depending on the state of the Sample/Summary command.
| Metric | Description |
| Idx# | The index id#. |
| Index Name | The index name. |
| Create | The number of index CREATE operations for this index. |
| Read | The number of index READ operations for this index. |
| Split | The number of index SPLIT operations for this index. |
| Delete | The number of index DELETE operations for this index. |
| BlkDel | The number of index BLOCK DELETE operations for this index. |
Top
Table Statistics
Tables that do not have _TableStat data available are indicated with a leading"*". (This may be because -tablebase or -tablerangesize need adjustment.)
Table Statistics Tbl# Table Name Create Read Update Delete TempTable ---- -------------------- --------- --------- --------- --------- --------- 377 job-queue 0 91749 40 0 500 order-lines 0 15848 0 0 178 orders 0 3254 28 0 248 inventory 0 1958 0 0 384 credit 0 117 0 0 522 scratch 4 111 4 4 *** 351 employee 0 75 13 0 382 warehouse 0 70 0 0
| Metric | Description |
| Tbl# | The table id#. |
| Table Name | The table name. |
| Create | The number of record CREATE operations for this table. |
| Read | The number of record READ operations for this table. |
| Update | The number of record UPDATE operations for this table. |
| Delete | The number of record DELETE operations for this table. |
Top
User Details
The first section shows specific details about the selected user (use the "e" command to select a usr#.)
User Details Usr#: 4393 Name: tucker PID: 12496 Device: CTX03 Transaction: 706471181 Blocked On: REC XQH:20626853:[customer] User 4393's Sessions Usr Name Flags PID DB Access OS Reads OS Writes Hit% ----- --------------- ----- -------- ---------- ---------- ---------- ------- 1247 tucker SB 3477718 486 2 0 99.51% 4393 tucker R 12496 8 0 0 100.00%
| Metric | Description |
| Usr# | The Usr# for the selected connection. |
| Name | The User Name associated with the selected connection. |
| PID | Operating system Process ID of the selected connection. |
| Device | The device that the user logged in to. May be an IP address or DNS name. |
| Transaction | Details from the "OpenTRX" screen if this user has an Open Transaction. |
| Blocked On | Details from the "Blocked" screen if this user is blocked on some resource. |
The second section shows UIO data for all sessions being run with the same User Name.
| Metric | Description |
| Usr | The Usr# for this connection. |
| Name | The User Name associated with this connection. |
| Flags | Connection type flags.
|
| PID | Operating system Process ID. |
| DB Access | The number of database block accesses that this user has requested. |
| OS Reads | The number of times that a database block accesses that this user has requested resulted in an OS read() operation. |
| OS Writes | The number of OS write() operations that this process has caused. |
| Hit% | The percentage of times that db blocks were found for this process in the buffer cache instead of being read from disk. |
Top
User IO Statistics
UIO Usr Name Flags PID DB Access OS Reads OS Writes Hit% CPU ----- -------- ----- -------- ---------- ---------- ---------- ------- -------- 5282 tom R 15732 4705 9 0 99.80% 4640 jami R 11980 3629 2 0 99.94% 5028 julia R 6512 3385 1 0 99.97% 4469 peter R 14532 2071 0 0 99.99% 708 emily SB 5251252 1525 0 0 99.99% 00:00:09 1018 tiger SB 2527484 1032 0 0 100.00% 00:00:25 5246 granite R 13228 913 0 0 100.00% 763 tucker SB 2777174 869 0 0 99.97% 00:00:11 992 lauria SB 3485876 850 1 0 99.86% 00:00:19 4217 carol R 17536 761 1 0 99.84% 4910 don R 13484 691 4 0 99.47% 827 tom SB 6623470 578 0 0 99.95% 00:00:23 1097 mike SB 5673202 492 0 0 100.00% 00:00:32 4763 tim R 11412 397 0 0 100.00% 5085 steph R 5572 396 0 0 100.00% 1183 steve SB 3281092 366 0 0 99.98% 00:00:16 1271 stacey SB 1183940 350 0 0 99.98% 00:00:07
| Metric | Description |
| Usr | The Usr# for this connection. |
| Name | The User Name associated with this connection. |
| Flags | Connection type and status flags.
|
| PID | Operating system Process ID. |
| DB Access | The number of database block accesses that this user has requested. |
| OS Reads | The number of times that a database block accesses that this user has requested resulted in an OS read() operation. |
| OS Writes | The number of OS write() operations that this process has caused. |
| Hit% | The percentage of times that db blocks were found for this process in the buffer cache instead of being read from disk. |
Top
Terms and Conditions of Use
Terms and Conditions of Use
All materials on this site are copyrighted by White Star Software LLC, all rights reserved. No content or programming code may be sold, published or distributed without express permission from the author except as described below.
Use of Source Code
All programming code on the site may be used, redistributed and/or modified under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License or (at your option) any later version.
No support, guarantee or warranty is offered or implied. By using any code found on this site you assume full risk and responsibility for that use.
Use of Other Materials
Articles or other informational material found on this site may not be posted or published elsewhere, in whole or in part, without express permission. You may, however, make copies for your own personal reference.
Alternative licensing is available.
OEMs, ISVs, VARs and others who wish to distribute ProTop with their commercial products, and who are not licensing and distributing their source code under the GPL, or who do not wish to be bound by the GPL need to purchase a commercial license of ProTop.
Licensing Terms can be tailored to meet the unique requirements of OEMs, ISVs, VARs and other parties interested in embedding, bundling, reselling or otherwise using ProTop outside of the GPL.
Top
Download & Installation
Installation Requirements
ProTop only works with a Progress version 9 or greater client due to its extensive use of Publish & Subscribe (aka "Named Events"). This feature is not available in earlier releases of Progress. Certain aspects of VST programming are also specific to v9 so not all modules will work if connected to a v8 database.
ProTop Packages
Base ProTop (Source Code, All Platforms)All installations require the Base Protop (above) to be downloaded first. R-code packages are applied as an add-on to the base package.
Version 9.1 r-code CharacterVersion 9.1 r-code GUI
OpenEdge 10.0a r-code Character
OpenEdge 10.1a r-code Character
Create a directory to install ProTop in such as /opt/protop and change to that directory. If upgrading from a previous release of ProTop I usually rename the old directory "protop.old" first just in case the upgrade fails. Extract the tarball (or tarballs). Modify any scripts that you might have or copy bin/protop and modify as needed. Take a look at etc/protop.cfg and decide if you need to modify any of the variables therein. Start a session against your target database. For instance:
$ cd /data/sports
$ PROPATH=/opt/protop; export PROPATH
$ mpro sports -p protop.p -param "i;10" -Bt 1024
will start the monitor against "sports" with a 10 second interval. The protop directory must be in the PROPATH (either explicitly or as ".").
Configuring Your Terminal
All displays will work properly on an 80x25 screen -- however ProTop will be much more useful if you define a "tall" terminal type in protermcap. The following protermcap entry will create a clone of a vt100 that is 40 rows long:
vt100-t|Tall vt100:\
:li#40:\
:tc=vt100:
There is also a protermcap.protop file included in the "etc" subdirectory. This protermcap defines a 36 row by 96 column "xterm" or "putty" terminal with colors that protop knows about.
Then just stretch your window to be 40 rows and change your TERM environment variable like so:
TERM=vt100-t export TERM
It is sometimes useful to tell the OS about your new terminal type as well ;-) You may want to add an entry similar to the PROTERMCAP entry to /etc/termcap (if your OS still uses it) or create a psuedo entry in the terminfo directory:
# cd /usr/share/terminfo/v # ln vt102 vt100-t
(Tangent: if there are both vt100 & vt102 entries use vt102 -- a "pure" vt100 is crippled in important ways. The vt102 is the "modern" baseline for the family.)
Top
Programming
Loadable Modules are persistent procedures. If a Loadable Module is in the protop/mon directory at startup or when a "mon-restart" event occurs that module will be automatically loaded and available.
Absolutely nothing should be shared. No shared variables. No shared temp-tables. (Except, of course, for the stuff that I have coded!)
All Loadable Modules should include {lib/protop.i} in their definitions. (Yes, it contains a couple of shared variables and some other sins that I'll probably fix eventually.)
A Loadable Module must publish a "register-disp-type" event on startup and it must subscribe to a "mon-restart" event.
To register a Loadable Module simply publish a "register-disp-type" with a single character string parameter -- the name of what it would like to display. Loadable Modules that support multiple display types must register each separately.
All Loadable Modules must subscribe to "mon-restart" and cleanup & delete themselves when a "mon-restart" occurs.
To be useful a Loadable Module might also want to subscribe to "mon-define", "mon-init", "mon-update" and "mon-display". These events are published by ProTop.p and are the main events that a Loadable Module needs to be sensitive to:
| Event | Description |
| Mon-Define | This event notifies a Loadable Module that it should read it's configuration file (if it has
one). Currently only the tt_xstat.p Loadable Module uses this feature. The configuration file is used to describe a set of dynamic queries of VST data. It's a lot of trouble for very little benefit. |
| Mon-Init | The "mon-init" event is published at startup and when the "z" command is issued. It is used to initialize the baseline data. Mon-init is also used to define the "schema" for the generic display drivers. |
| Mon-Update | "Mon-update" is used to drive the sampling of data. When a "mon-update" event is received
the Loadable Module samples its data and performs any needed aging of the data. Many modules will skip the actual update and aging if the currently active display is not set to one of their supported display types. This optimization improves performance at the cost of a "synchronization" iteration of the display when changing display types. |
Database selection is supported via the "dictdb" database alias. References to VSTs must refer to this alias for database switching to work. Scoping rules for VST references which must be pre-fixed with "dictdb." are subtle.
Data is displayed by generic "driver" programs. Currently there are drivers for ChUI, GUI and HTML displays.
The monitoring infrastructure supplies a number of global attributes that can be accessed via publish and subscribe. All attributes can be queried via "get-" and updated via "set-" events. The attributes and their usage are as follows:
| Attribute | Data Type | Key | Usage |
| CURR-DISP | Character | "d" | Curr-disp is the comma-delimited of currently active display types. |
| EXAMINE-ITEM | Integer | "e" | The value of this attribute is used in "drill down" screens to determine the item of interest. It is not context sensitive. If it is a usr# in one screen that same value will be used as the server# when switching to, for instance, a server drill down screen. |
| INTERVAL | Integer | "i" | The number of seconds between updates of the ProTop screens. |
| SORT-CRITERIA | Character | "s" | What sort-criteria to follow. There is no validation of the attribute and is without context (like examine-item). |
| TLIST | Character | "t" | A comma-delimited list of entities to track. This is generally implemented in the "update" routine to prevent needless processing of uninteresting data. But it could also be used to simply suppress non-matching entries at display time. |
| XLIST | Character | "x" | A comma-delimited list of entities to exclude. Like "tlist" this is generally implemented in the "update" routine to prevent needless processing of uninteresting data. But it could also be used to simply suppress matching entries at display time. |
Top