Article View: comp.archives
Article #2416[comp.unix.sys5.r4] svr4mon-0.2 alpha release announcement
From: Andreas Vogel
Date: Wed, 14 Oct 1992 11:58
Date: Wed, 14 Oct 1992 11:58
545 lines
24227 bytes
24227 bytes
Archive-name: auto/comp.unix.sys5.r4/svr4mon-0-2-alpha-release-announcement
I've finished the 0.2 alpha version of a (partially) new program named
svr4mon. I've actually taken the u386mon code as a strating base.
Altough the look and feel is much the same as in u386mon, the internal
structure changed drastically. This means that svr4mon ONLY runs on SVR4
unix as the name itself indicates :-))
Below I've included the README file for more information. Please no flames
on my bad english. Corrections are welcome and I want to give getting better.
I've located the 0.2 version on the below ftp-server. I need some people
who will test the code on portability and functioning.
Server: ftp.ims.uni-stuttgart.de (141.58.127.8)
Directory: pub/unix/svr4
File: svr4mon-0.2.tar.Z (81309 bytes)
svr4mon-0.2.README (2831 bytes) this is actually the same file
included below and it is
included in the tar archive
If there are enough people wanting me do post it I will then do so. But tell
me where (alt.sources,comp.unix.sys5.r4???).
As always, comments are welcome.
-------- CUT HERE --- CUT HERE ---------------------------------------------
S V R 4 M O N
A SVR4 system performance monitor
Version: 0.2
Last update: 13-OCT-1992
------------------------------------------------------------------------------
NOTE:
This is the first release of svr4mon. So it is definitely in an (pre-) alpha
state. It runs fine and without any crashes on my system and I think it
shouldn't give any problems to other SVR4's as well.
The documentation of the whole package is terrible and not yet finished.
Please report bugs, fixes or comments to av@ssw.de
And please don't forget, it's an alpha release.
------------------------------------------------------------------------------
This file contains a few comments about svr4mon.
"svr4mon" is a system monitor for SVR4 unix. It will give continual reports
about the state of the system. It requires read access to the memory files
"/dev/kmem" and "/dev/mem" as well as the system image "/stand/unix".
svr4mon requires terminfo style curses and will use color if you have
it. It works best with a 43 line (or greater) screen, but will work
with a 24 line screen with some limitations.
Features:
* display of overall system CPU and wait times
* display of sysinfo/minfo structures
* display of memory usage
* display of avenrun values and system age
* display of var structure
* display of bootinfo structure
* display of tune structure
* display of total process summary
* display of top X (somehow sorted) processes like ps(1)
* display of STREAMS utilisation
* display of architecture and hardware information
* display of FAS or SAS serial driver status variables (not yet well tested)
* one window of other unrelated kernel variables (misc)
* on-line interval changing (1 sec. steps)
* termlib color support
* efficient access to kernel structures using mmap(), therefor almost no
system calls and less CPU usage
Sample output (with 43-line screen)
===================================
svr4mon-0.1 S: SINIX-D R: 5.41 V: A0007 N: omega 22:53:15
---- CPU --- tot usr ker brk ---------------------------------------------------
2 Sec Avg % 100 92 7 0 uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuukkk*
10 Sec Avg % 78 68 10 0 uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuukkkkk
20 Sec Avg % 89 76 13 0 uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuukkkkkk
---- Wait -- tot io pio swp -- (% of real time) -------------------------------
2 Sec Avg % 0 0 0 0
10 Sec Avg % 20 20 0 0 iiiiiiiiii
20 Sec Avg % 10 10 0 0 iiiii
---- Sysinfo/Minfo --- (last 2000 msec activity) ------------------------------
bread 0 readch 10022 pswitch 30 vfault 0 unmodsw 0
bwrite 0 writch 73814 syscall 82 demand 0 unmodfl 0
lread 60 rawch 1 sysread 25 pfault 0 psoutok 0
lwrite 18 canch 0 syswrit 21 cw 0 psinfai 0
phread 0 outch 526 sysfork 0 steal 0 psinok 0
phwrite 0 msg 0 sysexec 0 frdpgs 0 rsout 0
swapin 0 sema 0 vfpg 0 rsin 0
swapout 0 maxmem 32384k runque 2 sfpg 0
bswapin 0 freemem 4368k runocc 2 vspg 0 pages on
bswapout 0 mem used 87% swpque 0 sspg 0 swap 0
iget 0 maxswap 65536k swpocc 0 pnpfault 0 cache 0
namei 0 freeswap 49516k Age of system wrtfault 0 file 0
dirblk 0 swap used 25% 2d 3h 14m avenrun 0.72 0.25 0.08
------ Var ------ ------ Bootinfo ------ ------ Tune ----- ----- Proc ----
v_autoup 60 bflags 00000000 t_ageintvl 0 sleep 60
v_buf 200 t_fsflushr 1 run 1
v_hbuf 256 memory available t_gpgshi 0 zombie 1
v_hmask 255 00000000 0000b000 t_gpgslo 42 stop 0
v_maxpmem 0 0000b000 00095000 t_minarmem 25 idle 0
v_maxup 60 00100000 01f00000 t_minasmem 25 onproc 1
v_pbuf 20 t_dmalimit 4096 xbrk 0
v_proc 600 memory used t_flckrec 1000 ---------------
v_call 250 00000000 00003000 t_minakmem 16 total 63
v_nglobpris 160 0000b000 00095000 KTXT in mem 63
v_maxsyspri 99 00100000 00099000 KTXT
v_sptmap 250 00199000 00030000 KDTA
v_bufhwm 2000
ESC=quit P,p=ps m=main h=hack s=stream x=serial a=arch l/u=lock +/-=rate
The main display
================
A brief description of reported information:
0. The '+' and '-' command adds or subtracts one second from the
update interval. The value at startup is 2 seconds, the
range 1 to 4. Below, the terms "x1", "x5" and "x10" mean
"interval X 1", "interval times 5" and "interval times 10,"
respectively.
You can determine the update interval by looking at the top
CPU histogram, labeled "Instant" for 1, "X sec" for 2-4 second
intervals.
On some *fast* systems, values may be too large in 3 and 4
second intervals and corrupt the display. But the, you have
the extra CPU to run it more often :-).
1. The CPU utilization is shown with smoothing of x1 ("instant" if
the update interval is 1 second), x5 and x10 seconds. Total
CPU usage is shown, with user, kernel and "break" subdivided.
Most performance utilities (vmstat) lump kernel (CPU_KERNEL)
and wait (CPU_WAIT) times together as kernel time. u386mon
considers CPU_WAIT time as idle (the CPU could have been
doing something if an otherwise ready process wasn't waited).
On a color display, total cpu utilization is displayed in
green if the cpu utilization is below 70%, yellow if utilization
is between 70% and 89% and red if 90% or above.
2. The Wait display shows the x1, x5 and x10 second smoothed
percentages of real time no process could be run because
otherwise ready to run processes were waiting on logical,
swap or physical I/O.
On a color display, total wait time is displayed in green if
it is below 30%, yellow if utilization is between 30% and 49%
and red if 50% or above.
3. Sysinfo/Minfo display shows, generally, the number of events
for a measured value since the last display update. For
example, runque shows the number of times a process was
placed on the run queue. An exception is the memory and swap
space fields: These numbers reflect absolute current
utilization over the period shown in the "last XXXXX msec"
value in the banner. Periods of 4000 milliseconds are shown
in red, 1500 to 3990 milliseconds in blue and less than 1500
milliseconds in the normal banner color.
My guess as to the meaning of the sysinfo and minfo values is
in the file EXPLAIN. I am not familiar with the meanings of
all the items, having looked through the header files, sar
man pages and the other UNIX hacker-ganda I could find.
Comments are appreciated.
4. If you run u386mon on a 43 line display, extra information is displayed
on the bottom of the screen (from the struct var v, bootinfo
and proc kernel databases).
On a 24/25-line screen, the 'e' command accesses the Var/Bootinfo/
Tune/Proc display, overlaying the Sysinfo/Minfo display.
Using 'm' returns you to the main display.
Bootinfo will be missing from version running on platforms which
do not support it.
5. On a color display, static numeric values, such as maxmem appear
in blue (the same color as screen literals/labels). Dynamic
numeric values are displayed in green, with the exception of
total cpu and wait percentages, which appear in light green,
red or yellow.
6. An "INEXACT" indication on the top line means that u386mon was
not scheduled quickly enough to capture accurate 1 second (nominal)
values. Continued INEXACT indication suggests the x5 and x10
second smoothed values are also wrong.
An "INVALID" indication means u386mon was scheduled 3 or more
seconds late; all percentage isplays are now suspect.
7. IN GENERAL, if you see any red characters on the display,
immediately take grain of salt. If you have no color screen
and still see red, add tequila to salt.
8. If you are running as root, you may use the -l switch or the
'l' command to lock u386mon into memory. If you do this, PLOCK
will appear at the top of the screen to remind you of this hoggy
behavior. The u386mon process will not be listed in a process
status display since SSYS (locked, resident) processes are not
shown.
Process Status Display
======================
1. Pressing 'p' causes a process status display of sorts to be
shown, overlaying Sysinfo/Minfo on a 25 line screen or
Var/Bootinfo/Tune/Proc on a 43 line screen. On a 43 line screen, 'P'
causes a larger ps display to be shown, overlaying Sysinfo/Minfo and
Var/Bootinfo/Tune/Proc.
Sample output:
S USER PID CPU PRI NI UCPU SCPU SIZE TTY COMMAND
R av 10700 80 2 0 0:06 0:00 440 23 /usr/ccs/bin/as -Qy -o main.
p root 10701 11 34 0 0:01 0:00 400 15 ./svr4mon -p
s root 258 2 48 0 13:43 5:27 1204 ?? /usr/bin/X11/X -switch -pn -
s root 633 1 48 0 0:03 0:05 456 ?? /usr/bin/X11/xterm -geometry
s root 631 0 48 0 2:02 3:55 456 ?? /usr/bin/X11/xterm -geometry
s root 627 0 48 0 1:11 0:17 456 ?? /usr/bin/X11/xterm -geometry
s root 634 0 48 0 0:20 0:28 456 ?? /usr/bin/X11/xterm -geometry
s root 632 0 48 0 0:15 0:24 456 ?? /usr/bin/X11/xterm -geometry
s root 630 0 48 0 0:14 0:22 456 ?? /usr/bin/X11/xterm -geometry
s av 657 0 48 0 0:14 0:23 436 ?? mwm
s root 734 0 35 0 0:13 0:17 564 14 tcsh
s root 10473 0 48 0 0:09 0:07 456 ?? xterm -geometry 80x24+1+353
s root 10439 0 46 0 0:07 0:11 1068 14 /usr/bin/m -def=/usr/lib/MAX
s av 636 0 48 0 0:06 0:23 312 ?? /usr/bin/X11/xload -geometry
s root 751 0 46 0 0:04 0:02 564 18 tcsh
s root 2376 0 46 0 0:03 0:03 564 13 tcsh
s av 671 0 35 0 0:03 0:03 564 /3 tcsh
s root 146 0 48 0 0:03 0:12 284 ?? /usr/sbin/cron
s root 2044 0 35 0 0:02 0:02 564 15 tcsh
s av 667 0 35 0 0:02 0:02 564 16 tcsh
s root 438 0 46 0 0:02 0:01 564 02 -tcsh
s av 665 0 35 0 0:02 0:01 564 13 tcsh
s root 5494 0 46 0 0:02 0:01 564 /3 tcsh
s av 669 0 35 0 0:02 0:00 564 18 -tcsh
PROCS OMITTED: 39
NOTES
a. S - two character status
1st character - process status
s - sleeping
R - ready to run (might be running if u386mon were not)
z - zombie
d - stopped by debugger
i - idle (in creation?)
p - running on processor (on single CPU systems, only u386mon
will show this)
x - XBREAK - process growing or shrinking
2nd character - process swap status
S - process is swapped
blank - process is in memory
b. If the process is running with setuid, a '#' appears to
the right of the username.
c. On color systems, processes ready to run are shown in yellow
unless they are ready, but swapped out, in which case they
are shown in red.
3. Since a limited space is available for displaying process
status, particularly on a 25-line screen, a selective elimination
algorithm is used to whittle the list when insufficient room
is available. init (pid 1) and system/resident (SSYS)
processes are never displayed. When a display cycle is to begin
and there is not room for all of the processes to be shown,
processes are sorted in the following order:
a. 'getty', 'uugetty', 'sh', 'csh', and 'ksh'
b. swapped and zombie processes
c. no cpu processes (no cpu time during last cycle)
d. sleeping processes
If there is still insufficient room, an indication to the effect
is displayed (tough cookies).
STREAMS display
===============
This display shows STREAMS queues and buffers utilization of the system.
Sample output:
--------------------------------------------------------------------------------
RESOURCE ALLOC IN USE FREE TOTAL MAX FAIL
Streams 144 144 0 6700 152 0
Queues 716 716 0 14528 720 0
Message blocks 508 122 630 1784031 2014 0
Data blocks 507 122 385 1784025 2013 0
Link blocks 15 15 0 15 15 0
Stream events 2 2 0 2 2 0
strmsgsz: 0k
strctlsz: 4096k
nstrpush: 9
strthresh: 0k
SERIAL display
==============
Currently only FAS and SAS statistics are supported. I'm using my own
port of FAS to SVR4 and I don't know if it works with the original FAS
driver (which is designed for SVR3 but may run on SVR4). I've added
support for SAS but I haven't tested it yet.
See config.h in order to enable one or none of them.
Sample output:
---- FAS statistics ------------------------------------------------------------
Port: 0 Type: NS16450 Units: 1 Vec: 4 Sioa: 3f8 SioaOff: 8 Mcb: 8
iflag: IGNBRK BRKINT IGNPAR PARMRK INPCK ISTRIP INLCR IGNCR ICRNL IUCLC
IXON IXOFF IXANY
cflag: 9600-8-O-1 CLOCAL CREAD HUPCL
device_flag: OPN LCK ENBL XBSY XBRK XLCK HANG DTIM GTIM CARR WANT
o_state: DLOUT GTTY WOPN NDIAL CCOO FCO UNEN CL HWHS
flow_flag: HWOHS HWIHS HWOSTP HWISTP SWOSTP SWISTP SWFCREQ RXFER IBLK
mod_stat: CTS_DLT DSR_DLT RING_TDG DCD_DLT CTS_PRS DSR_PRS RING_PRS DCD_PRS
cstart: 0x11 cstop: 0x13 hupwait: 0
Port: 1 Type: NS16550A Units: 1 Vec: 3 Sioa: 2f8 SioaOff: 8 Mcb: 8
iflag: IGNBRK BRKINT IGNPAR PARMRK INPCK ISTRIP INLCR IGNCR ICRNL IUCLC
IXON IXOFF IXANY
cflag: 9600-8-N-1 CLOCAL CREAD HUPCL
device_flag: OPN LCK ENBL XBSY XBRK XLCK HANG DTIM GTIM CARR WANT
o_state: DLOUT GTTY WOPN NDIAL CCOO FCO UNEN CL HWHS
flow_flag: HWOHS HWIHS HWOSTP HWISTP SWOSTP SWISTP SWFCREQ RXFER IBLK
mod_stat: CTS_DLT DSR_DLT RING_TDG DCD_DLT CTS_PRS DSR_PRS RING_PRS DCD_PRS
cstart: 0x11 cstop: 0x13 hupwait: 10
1) Pressing 'x' causes the above display to be shown. If you're using a
24 lines display, you'll see only 1 port at a time. Pressing any key
in the range '0' - '9' will show the port with that given number.
HACKERS (or MISC) display
=========================
The display shows variables which might be interesting. I couldn't
find a reasonable topic for any of them so they are here.
Sample output:
--------- Hackers Variables ----------------------------------------------------
lotsfree 324k minhidustk 16384 dma_check_on 1 Dstflag 1
desfree 168k minustkgap 8388608 dma_freemem 951 maxminor 262143
minfree 100k piosegsz 1024 dma_io_slots 10 putbufsz 4000
nscan 0k syssegsz 2048 dma_limit_pfn 4095 sanity_clk 0
desscan 100k segmapsz 2024 dma_single 1
maxpgio 40 piomapsz 50 dmaable_free 40 ncsize 700
deficit 0 piomaxsz 64 dmaable_pages 40 filecnt 223
freemem 6180k pages_pp_max 200 dmaable_sleep 0 maxclick 8192
pfreecnt 20 minpagefree 25 pfreecnt 20
nptfree 0 nptalloced 0 ngroups_max 16
availrmem 24508k npgoutbuf 32 rstchown 0
availkmem 18060k nnotpgoutbuf 32 Hz 100
availsmem 73592k exec_ncargs 51200 Timezone 480
HARDWARE & ARCHITECTURE display
===============================
The display shows the hardware configuration and installed hard
drives of the system.
Sample output:
--------- Hardware configuration -----------------------------------------------
ID DISK TYPE #CYL SEC/TRK #PART #HEADS BYT/SEC ALTS CAPACITY
0 0s0 SCSI_HD 1030 32 11 64 512 2048 1030 MB
?? c8d1s0 SCSI_HD 573 32 ?? 64 512 ?? 573 MB
Floppy 0: 1.44MB 3.5" Floppy 1: 1.2MB 5.25"
Main Processor: i386
Math Processor: i80387 do386b1: 0 do386b1_387: 0 do386b1_x87: 0 do387cr3: 0
Base Memory: 640k Extended Memory: 31744k Expanded Memory: 31744k
How to get going
================
1) Take a look to the Makefile. Check the varibales for comilation
and installation.
2) Take a look to config.h and define or undefine the symbols you need.
3) make depend
4) make
5) ./svr4mon
6) make install (as root)
7) Enjoy :-))
Programming Concepts
====================
The major advantage of this program is it's use of mmap() instead of read()
and lseek() as in "traditional" comparable programs. Using mmap() no further
system calls are neccessary to access kernel variables.
In order to access a kernel variable the address of the kernel variable
is translated to an address in user process space. The base address in user
process space is determined at startup by calling mmap() without giving
any hints where the map should be placed. The result of this call to mmap()
is taken as our base address. The kernel address space ranges from
0xC0000000 to 0xE0000000. Typically the first call to mmap(), which gives
us the base address for our user space mapped pages, is somewhat higher
than 0x80000000 (the start address for shared libraries).
Starting at the base address all pages which are mapped during execution
must be arranged in ascending order and must be contigious.
If we now want to access a kernel variable, we take the address and translate
it to a address relative to our base in user space. If we then try to access
data through that pointer two conditions can raise:
1) The page holding that address is not yet mapped. As a result a signal
SIGSEGV will be produced and a signal handler, which was previously
installed, is called. This signal handler determines the page which holds
this address and maps the page via mmap(). The signal handler then
returns and the instruction which caused the fault will be restarted.
2) The page holding that address is currently mapped, no problems arises.
So we have a demand paging system which only loads neccessary pages.
At startup time no pages are mapped and after the first cycle most
pages are mapped then.
Using this method, access to kernel variables is just the same as the
access to "ordinary" variables in user space. The mapping of the
required pages is (almost) transparent to the programmer. I think it's
really faster than using the lseek()/read() method.
I hope you got the idea and I'm very interested in getting comments on
this method.
COPYRIGHT
=========
Copyright (C) 1992 Andreas Vogel
This program is free software; you can redistribute it and/or modify
it 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.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Acknowledgments
===============
This code is based on u386mon written by wht@n4hgf.Mt-Park.GA.US (Warren
Tucker) for SVR3 unix. Thanks to the author for this excellent program.
But if you have problems with svr4mon please don't contact him because he
wasn't involved in the developement of svr4mon.
Contibutors
===========
Thanks to:
bl@ssw.de (Benno Lange)
sv@ssw.de (Stefan Vogel)
Bo.Muldbak@ColumbiaSC.NCR.COM (Bo Asbjorn Muldbak)
andreas@xenox.w.open.de (Andreas Laumann)
If your name appears on the above list and I've forgotten a
particular contribution you made, or if it doesn't appear at all,
please forgive me.
HOW TO GET svr4mon
==================
I will try to put the latest version of svr4mon on the following FTP server:
Server: ftp.ims.uni-stuttgart.de (141.58.127.8)
Directory: pub/unix/svr4
File: svr4mon-<v>.<r>.tar.Z
(where <v> stands for the current version and <r> for the release)
I also will post new releases to alt.sources or if applicable patches for
updating from old versions.
Please don't ask me to send out versions via mail.
Hope that's all,
------------------------------------------------------------------------------
Andreas Vogel Bahnhofstr. 13 / D-7300 Esslingen / Germany
Voice: +49-711/357613
E-Mail: av@ssw.de
-------- CUT HERE --- CUT HERE ---------------------------------------------
So long,
--
Andreas Vogel Bahnhofstr. 13 / D-7300 Esslingen / Germany
Voice: +49-711/357613
E-Mail: av@ssw.de
Technical Details
Message-ID:
<1bh20dINNs3q@agate.berkeley.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!elroy.jpl.nasa.gov!ames!agate!agate!usenetReferences:
<1992Oct13.205921.19233@omega.ssw.de>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!elroy.jpl.nasa.gov!ames!agate!agate!usenet From: av@omega.ssw.de (Andreas Vogel) Newsgroups: comp.archives Subject: [comp.unix.sys5.r4] svr4mon-0.2 alpha release announcement Followup-To: comp.unix.sys5.r4 Date: 14 Oct 1992 11:58:05 GMT Organization: Omega Softlab Lines: 546 Sender: adam@soda.berkeley.edu Approved: adam@soda.berkeley.edu Distribution: world Message-ID: <1bh20dINNs3q@agate.berkeley.edu> References: <1992Oct13.205921.19233@omega.ssw.de> NNTP-Posting-Host: soda.berkeley.edu X-Original-Newsgroups: comp.unix.sys5.r4,comp.unix.sysv386 X-Original-Date: Tue, 13 Oct 1992 20:59:21 GMT