Jane,
I fear this isn't really interesting for the "normal" NetView user.
The created Autotrace packages are in binary format and you need a special
viewer
and a code database for the traced product to view them.
It is only there for support. Preverably L3 support.
Nervertheless the atctl command reference for your curiousity ;-):
--------------------------
NAME
atctl - AutoTrace runtime control
SYNOPSIS
atctl [-vfk] [cmd [arg ...]]
DESCRIPTION
atctl controls the runtime operation of AutoTrace. It provides commands to
manage configuration and
trace point activity, control channel recording, snapshot channels to disk,
and display status
information. Most commands require arguments to target their effect. If a
command is specified
incorrectly, or if no command is named, atctl displays a brief reminder of
command syntax.
OPTIONS
-v Select verbose output.
-f Force; command specific.
-k Keep; command specific.
COMMANDS
init [path]
This command creates and initializes the AutoTrace control channel; no
tracing
is possible until initialization is completed. After initialization, this
command can
be used to update the list of products available for tracing.
One or more files are used during the initialization or update process.
path is
either a file containing product information (see product(4at)), or a
directory
containing a file named product. If path is not specified, the platform
specific
default is used. The directory may optionally contain product-specific
configuration in a file named config (see below), and also optionally a
file
specifying the trace IDs to automatically enable, named ffdc. These files
are
only processed if the product was not already known to the AutoTrace
runtime.
See the commands config and trace for more information.
product [path]
product displays the set of products currently known to the runtime. The
argument path directs product to process the named product file, merging
it
with any existing runtime product list. path is either a file, or a
directory
containing a file named product. The contents of this file are used to
update
the set of known products.
config [path]
config displays the current runtime configuration. The argument path
directs
config to process the named configuration file, merging it with any
existing
runtime configuration. path is either a file or a directory containing a
file named
config. The option -f is used to replace the runtime configuration instead
of
merging.
trace product
on product [list [...]]
off product [list [...]]
The trace, on and off commands display and control which trace points are
recorded from programs compiled by AutoTrace. The effect is global - all
programs with the same product id are equally affected. The trace command
displays all active trace points for product as a list of ranges, one per
line. The
output is usable as input to the on and off commands. The command
atctl trace snox > ffdc
writes to ffdc all the active trace points for the product snox.
on and off are used to enable and disable a list of trace points in the
instrumented executable. These trace points are added or removed from the
current set of active trace points for the named product. List is an
integer, a
range, a file containing a list, the word all, or a combination of these,
separated
by spaces. Ranges are integer values separated by dashes, inclusive of the
specified values. The command
atctl on snox 1000 1003 1005-1007 ffdc
enables, for the product snox, the trace points 1000, 1003, 1005, 1006,
1007,
and all the trace points contained in the file named ffdc. The file stdin
is named
by using a dash (-). The command
echo 1000 1003 1005-1007 ffdc | atctl on snox -
produces the same result as the previous example. If list if not given on
the
command line, all trace points are enabled/disabled.
The command on accepts the option -f. This clears all trace points before
the
on, forcing only the named trace points to be active.
snapid product
snapid product file list [...]
snapid product on list [...]
snapid product off [list [...]]
The snapid command installs a directive within the AutoTrace
instrumentation
to cause an automatic snap whenever the specified trace point is reached.
Its
use is similar to the on and off commands, except that the list parameter
is
required for file/on. The file parameter is the pathname the automated snap
is
written into. If the off command has no arguments, (implying 'all'), the
snapid
directive is disabled, and all allocated resources are returned to the
system.
diff file1 file2
This command compares the trace points in file1 against file2. Either
filename
may be specified as a product name or product id, which will output the
differences between the active trace points for that product with the named
file.
echo 10000-10010 10020 10030 > foo
echo 10000-10005 10008 10020 | atctl on snox
atctl diff foo snox
info
This command displays the existing AutoTrace channels, as well as status
information for each, including their size, number of lifetime records
logged, and
channel creation date and time.
snap channel [path]
The snap command takes a snapshot of the trace records in the named
channel, writes them to disk, then performs an automatic reset. Trace
records
are written to snap%c_%u.at in the current directory unless an alternate
path
is provided. The variables %c and %u in path are replaced by the channel
number and a unique number that counts from 00 to 99. The snapshot is an
encoded, binary format understood by atrpt, and cannot be correctly decoded
without access to the product-specific database (see atdb(1at)). The output
file
is the same size as the trace channel, and can be quite large (many
megabytes).
The -k option instructs snap to keep the trace channel information by
omitting
the automatic reset. -f forces the snap to occur even if the channel
contains no
data.
suspend channel
resume channel
These commands suspend (resume) tracing to the designated channel. A
suspended channel retains all accumulated trace records, but disallows
further
recording of trace records. Programs continue running without pause, but
trace
information is no longer recorded. Tracing may be resumed at any time.
reset channel
A reset discards all the trace records in the channel, but tracing is not
otherwise affected.
remove channel
This command destructively removes trace channels, returning their
resources
to the system. All trace records present in removed channels are lost.
Channel
is a list of one or more integers or ranges, or the word all.
version
This command reports the current version of the atctl program. The
AutoTrace
library version is only reported if different from atctl, or if the -v
option is
present.
dump channel [length [offset]]
dump displays the encoded trace data in a hex dump for mat. By default, the
entire channel is dumped. Any portion of channel may be dumped by giving
length and offset. The internal structure of the channel is undocumented
and
subject to change without notice.
FILES
/etc/autotrace
C:\winnt\system32\autotrace
Default AutoTrace configuration directory (used only by init).
snap%c_%u.at
Default snapshot filename. %c is replaced with the channel number, %u with
a
number from 00-99, chosen to prevent accidental overwrites.
EXAMPLES
Initialize and enable AutoTrace using the files found in /opt/widget.
# atctl init /opt/widget
Turn off all currently active trace ids for the product snox, reset trace
channel 1, enable trace ids 10000
through 10100, plus trace ids 10200 and 10300, and report the trace ids
just enabled.
# echo 10000-10100 10200 10300 > bar
# atctl off snox
# atctl reset 1
# atctl on snox bar
# atctl trace snox
Display all AutoTrace channels, including supplementary information.
# atctl -v info
Copy trace channel 1 into the file snap1_00.at in the current directory,
then reset the channel. The
output file can be decoded with atrpt.
# atctl snap 1
EXIT CODE
atctl sets the exit code to zero for success, and non-zero if a problem is
encountered.
DIAGNOSTICS
AutoTrace not initialized
The AutoTrace control channel does not exist. Use the init command.
Cannot read /etc/autotrace/products
The init command was named with no arguments, and the default product file
does not exist.
SEE ALSO
atrpt, trace, snap, ctl, traceid, config, product
--------------------------
Kind regards
Oliver Bruchhaeuser
Tivoli NetView EMEA L2 Support
|---------+----------------------------->
| | Jane Curry |
| | <jane.curry@skills|
| | -1st.co.uk> |
| | Sent by: |
| | [email protected]|
| | s.ibm.com |
| | |
| | |
| | 26.11.2003 11:59 |
| | Please respond to |
| | nv-l |
| | |
|---------+----------------------------->
>-----------------------------------------------------------------------------------------------------------------------------|
|
|
| To: nv-l AT lists.us.ibm DOT com, tme10 <tme10 AT lists.us.ibm
DOT com> |
| cc:
|
| Subject: Re: [nv-l] 7.1.4 performance ?
|
|
|
|
|
>-----------------------------------------------------------------------------------------------------------------------------|
Does anyone have any more info about the atctl command used to control
the NetView First Failure Data Capture (FFDC) tracing facility? I have
seen a couple of reference to atctl on the tme10 forum also but "man"
gives no response, atctl -h is not very helpful, it is not in the new NV
Admin Ref guide and even google doesn't seem to have any relevant hits!
Cheers,
Jane
Oliver Bruchhaeuser wrote:
>Channing,
>
>yes you are right.
>Autotrace slow down ovtopmd start and ovtopofix.
>There is a test fix (IY50663)available from support.
>Of course you can also disable Autotrace (see the Release Notes how to do
>this).
>
>Kind regards
>
>Oliver Bruchhaeuser
>Tivoli NetView EMEA L2 Support
>
>
>
>|---------+---------------------------->
>| | "Hill, Channing" |
>| | <CHill AT bbandt DOT com|
>| | > |
>| | Sent by: |
>| | owner-nv-l@lists.|
>| | us.ibm.com |
>| | |
>| | |
>| | 21.11.2003 21:27 |
>| | Please respond to|
>| | nv-l |
>| | |
>|---------+---------------------------->
> >
------------------------------------------------------------------------------------------------------------------|
> |
|
> | To: "'nv-l AT lists.us.ibm DOT com'" <nv-l AT lists.us.ibm DOT
> com>
|
> | cc:
|
> | Subject: RE: [nv-l] 7.1.4 performance ?
|
> |
|
> |
|
> >
------------------------------------------------------------------------------------------------------------------|
>
>
>
>Never mind on the question about the "ovwdb_FFDC:5" being added to the
>ovwdb
>entry in ovsuf. I just found out via the release notes, page 8, that FFDC
>entries is for extensive tracing of Netview daemons. I also found an APAR
>(IY50663), that this auto tracing function can affect system performance.
>It
>appears to be turned on by default...(look in
>/usr/OV/conf/FFDC/autotrace.properties) I will totally disable this
>functionality and see if my performance improves. I'll let ya know....
>
>Channing Hill
>EMS Analyst II
>BB&T
>(252) 246-3642
>
>
>-----Original Message-----
>From: Hill, Channing
>Sent: Friday, November 21, 2003 2:48 PM
>To: 'nv-l AT lists.us.ibm DOT com'
>Subject: RE: [nv-l] 7.1.4 performance ?
>
>
>I got the cache size from ps -ef | grep ovwdb. The active entry in ovsuf
>has
>41000 as well. I did note an extra item appended to the line though.......
>
>7.1.4 has....
>0:ovwdb:/usr/OV/bin/ovwdb:OVs_YES_START:nvsecd:-O,-n41000,
>-t:OVs_WELL_BEHAVE
>D:15:/usr/OV/conf/FFDC/scripts/ovwdb_FFDC:5:
>
>7.1.3 FixPack1 has....
>0:ovwdb:/usr/OV/bin/ovwdb:OVs_YES_START:nvsecd:-O,-n41000,
>-t:OVs_WELL_BEHAVE
>D:15:::
>
>Any idea what the "ovwdb_FFDC:5" means?
>
>Please note that my performance hits only occur when stopping and starting
>the daemons or after running maintenance. Once things are up and running,
>performance is ok. Everything is configured correctly....DNS, paging, etc.
>>From the other replies, it may appear that this could be something we
have
>to live with on 7.1.4, if you manage large environments.
>
>Channing Hill
>EMS Analyst II
>BB&T
>(252) 246-3642
>
>
>-----Original Message-----
>From: Stephen Hochstetler [mailto:shochste AT us.ibm DOT com]
>Sent: Thursday, November 20, 2003 6:43 PM
>To: nv-l AT lists.us.ibm DOT com
>Subject: RE: [nv-l] 7.1.4 performance ?
>
>Channing,
>
>It sounds like you are experienced...but I just want to verify how you
>verifiied the cache.. did you look in your ovsuf file or in the
>ovwdb.lrf ....or at the line on a ps -ef command to see how ovwdb was
>started? I just make sure your ovwdb.lrf is 'active' in your ovsuf
file.
>(it is the 0 record that is active I think)
>
>With this upgrade, did you also upgrade AIX, networking ...or any other
>configuation change (that should have not affected things) ? Do you
>still have good DNS connectivity? I assume with the install that you may
>have rebooted your server. Does the paging space still look healthy?
>
>Stephen Hochstetler shochste AT us.ibm DOT com
>International Technical Support Organization at IBM
>Office - 512-838-6198 (t/l 678) FAX - 512-838-6931
>http://www.redbooks.ibm.com
>
>-------------------------------------------------------------------
>From: Jane Curry [mailto:jane.curry AT skills-1st.co DOT uk]
>Sent: Friday, November 21, 2003 3:33 AM
>To: nv-l AT lists.us.ibm DOT com
>Subject: Re: [nv-l] 7.1.4 performance ?
>
>
>Yup - I've seen the same thing. Again an upgrade from 7.1.3 FP1 to 7.1.4
>on AIX 5.1. No other changes made. I also have Switch Analyzer
>installed and that often fails to come up with the other daemons -
>perhaps a timeout issue because the rest of the daemons take so long??
>ITSA comes up fine if you start it manually.
>
>Not really had time to investigate this yet but hoping to do so next
>week.....
>
>Cheers,
>Jane
>
----------------------------------------------------------------------------
>
>----
>-----Original Message-----
>From: Barr, Scott [mailto:Scott_Barr AT csgsystems DOT com]
>Sent: Friday, November 21, 2003 9:00 AM
>To: nv-l AT lists.us.ibm DOT com
>Subject: RE: [nv-l] 7.1.4 performance ?
>
>
>I see higher OVWDB CPU consumption on 7.1.4 than I did on 7.1.3
>
>
>
>
>
>
>
>
>
--
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2003 Jane Curry <jane.curry AT skills-1st.co DOT uk>. All rights
reserved.
|
