NMON_Analyser is designed to complementNMON (Nigel’s Monitor) in analysing and reporting performance problems; it producesgraphs for virtually all sections of output created using the “spreadsheetoutput” mode of NMON as well as doing some additional analyses for ESS, EMC andFAStT subsystems. It will also work withfiles produced by topasout and with other tools that produce data in “NMON”format. It is written in VBA for Excel and will work with Excel 2003 or later.

NMON was originally written by NigelGriffiths (nag@uk.ibm.com)and is now (since AIX 5.3 TL09 and AIX 6.1 TL02) part of topas. NMON_Analyser is written/maintained byStephen Atkins (steve_atkins@uk.ibm.com) . Both Nigel and Stephen aremembers of the Systems and Technology Group in IBM.

Support for NMON_Analyser is provided ona best efforts basis. Please directquestions to the User Forum (see below) rather than contact the author direct.

Links:

NMON_Analyserhome page

http://www-941.haw.ibm.com/collaboration/wiki/display/Wikiptype/nmonanalyser

User Forum

http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=749&cat=56

New in V3.3

Support for new features in NMON12for POWER6 and AIX V6.1
Improved support for topasout and Linux
Dynamic invokation of Windows SORT command for large files
Automatic support for locales that use comma as a decimal separator
New facility to allow merging of NMON files for trend analysis
Automated creation of user-defined PivotChart
Removal of SVCTimes option (replaced by new sheet from NMON12)
Removal of DISKSORT option in preparation for Analyser V4
Changed REPROC option to work in all multi-file situations
New summary workbook for multi-file mode

Stephen Atkins, MBCS CITP

Consulting IT Specialist

IBM Systems and Technology Group

IBM UK

Stephen Atkins/UK/IBM or steve_atkins@uk.ibm.com

Preface. 1

New in V3.3.. 1

Table of Contents. 2

Collecting datausing NMON... 4

Collecting datausing topas (xmwlm). 5

UsingNMON_Analyser. 5

Analyser options. 6

National LanguageSettings. 7

Batch ProcessingOptions. 7

Formatting Options. 7

Pivot Chart. 8

Printing Options. 8

Web PublishingOptions. 8

Interpreting theoutput sections. 8

Notes on the“Weighted Average” as used in the Analyser. 8

General notes forDISK, ESS, EMC, FASt and DG sheets. 12

EMC/PowerPathsubsystems. 13

EMCBSIZE/FAStBSIZE.. 15

EMCBUSY/FAStBUSY... 15

EMCREAD/FAStREAD... 15

EMCWRITE/FAStWRITE.. 15

EMCXFER/FAStXFER... 15

EMCSERV/FAStSERV... 15

MEMPAGES4K/64K/16MB/16GB... 20

RAWCPUTOTAL,RAWLPAR... 23

TCPUDP.. 23

TOP.. 23

Interpreting the%Processor by PID chart. 24

Knownbugs/problems (V3.3, topas_nmon). 26

How to report aproblem... 27

Excel/VBA Resources/Links. 27

Appendix: Notes onBatch Operation.. 28

Sample .bat files. 28

NMON Analyser Batch.xls. 28

Collecting data using NMON

Please make sure you have the latestversions of both NMON and NMON_Analyser before starting a new engagement. If you want automatic notification of a newrelease of the Analyser send a note to steve_atkins@uk.ibm.com andI’ll add you to my distribution list.Nigel maintains a similar list for NMON.

You will need to have root privileges inorder to get a complete set of data on the BBBP sheet. In order to collect data for the DISKBUSYsheets you need to make sure that iostat data collection is enabled:

chdev -l sys0 -a iostat=true

For spreadsheet output mode (commaseparated values) use the following flags when invoking nmon:

-f spreadsheet output format [note: default -s300 -c288]

Output file is <hostname>_YYYYMMDD_HHMM.nmon

-F <filename> same as -f but user supplied filename

-c <number> numberof snapshots

-d requests disk service and wait times (DISKSERVand DISKWAIT)

-i <percent> Ignore processes using less than this amount of CPU when generatingTOP section – useful for reducing data volumes

-g <filename> file containing disk group definitions

-l <dpl> number of hdisks per sheet - defaults to 150,maximum 250. See notes

-m <dir> NMONchanges to this directory before saving the file

-r <runname> goesinto spreadsheet file [default hostname]

-s <seconds> interval between snap shots

-x capacity planning (15 mins for 1 day= -fdt -s900 -c96)

-t include top processes in the output

-T as –t plussaves command line arguments in UARG section

-A include data for async I/O (PROCAIO) sections

-D prevents DISK sections being produced (useful when Disk Groups arebeing used because there are too many hdisks to process)

-E stops ESS sections being produced (necessary when Disk Groups arebeing used because there are too many vpaths to process)

-J prevents JFSsections being produced (prevents Excel errors when you have more than 255filesystems)

-L includes LARGEPAGE section

-N include NFS sections

-S include WLM sections with subclasses

-W includeWLM sections without subclasses

-Y include SUMMARY section (very efficient alternative to –t if PID level data is not required)

example: nmon_aix51 -Fasterix.nmon -r Test1 -s6 -c12

Notes:

1. The –f (or –F) flag must appear first.

2. The value of the -l flag controls the number ofhdisks per sheet on the DISK sheets and per line on the BBBD sheet. There are two factors to consider whenchoosing this value. Excel has a limitof 256 columns per sheet; however, both NMON and NMON_Analyser use some columns,so the upper limit is really 250. Thesecond factor is that Excel VBA has an upper limit of 2048 bytes for input linelength. This particularly affects usersof EMC systems that use long hdisk names (e.g. hdiskpower123). The defaultof 150 is safe for such systems. Otherusers may set the value to 250 in order to reduce the number of output sheets.

3. Consider the value of the -s flagvery carefully. The shorter theinterval between snapshots, the more variable the values for each resource willbe. If you use an interval of 1 second,don’t be surprised to see many of your disks hitting 100% busy for shortperiods. For normal monitoring,10-minute intervals (-c 600) provide a good balance.

4. The graphs produced by NMON_Analyser look best when the number ofsnapshots (specified by the -c flag) is 300 or less.

5. The TOP section (produced by specifying the -t flag) can generate large amounts of output and the size of theoutput can grow exponentially if a large value is specified for the -c flag. If you want the TOPsection then specify no more than 250 snapshots - ideally less.

Collecting data using topas(xmwlm)

You need AIX V5.3 TL5 Service pack 4 withAPAR IY87993 or later. Note that onlythe output using the –a flag can be analysed. Inparticular, cross-partition statistics cannot be analysed; if you wish to get areport for the entire machine, collect data from each LPAR separately and thenuse NMON_Consolidator to merge the data.Commands like the following are required to collect the data.

topasout -a/etc/perf/daily/xmwlm.yymmdd

cp /etc/perf/daily/xmwlm.yymmdd_01hostname.ddmmyy.topasout.csv

UsingNMON_Analyser

·FTP the input file to your PC –ideally using the ASCI or TEXT options to make sure that lines are terminatedwith the CRLF characters required by Windows applications.

·Open the NMON_Analyser spreadsheetand specify the options you want on the “Analyser” and “Settings” sheets (seebelow). Save the spreadsheet if you want to make these options your personaldefaults.

Click on the "Analyse nmon data" button and find/selectthe .nmon file(s) to be processed. Youmay select several files in the same directory.If you wish to process several files in different directories you maywish to consider using the “FILELIST” option described below.

You may see the message SORT commandfailed for “filename” if the file has >65Klines and the filename (or directory name) contains blanks or specialcharacters. Either rename thefile/directory or just pre-sort the file before using the Analyser.

Analyser options

GRAPHS The first option is either ALL or LIST. If the value is LIST then only those sheets which appear in the LIST on the Settingssheet will have graphs drawn for them.This option is particularly useful if the graphs are to be printed/publishedor to reduce the amount of memory/fonts/disk space required when analysingfiles from large systems.

The second is either CHARTS, PICTURES, PRINT or WEB. The meaning of these are as follows:

·CHARTS produce Excel charts in-place onthe selected sheets

·PICTURES graphs will be produced on aseparate “Charts” sheets as pictures.Selecting this option can reduce the size of the output file by up to90%.

·PRINT implies PICTURES. Pictures will be printed to the designatedprinter (see “Printing Options” below)

·WEB implies PICTURES. Automated web publishing (see “Web Publishing”below)

INTERVALS specifies the first and last time interval tobe processed. Intervals outside thisrange will be discarded after parsing.Note that these are numbers between 1-99999 and are not timevalues. Setting a value of 2 for thefirst interval is useful in discarding the very large numbers that often appearat the start of an NMON collection run with AIX. If you have used a splitter program on theinput file, or if you are analysing data from a LINUX system, then you shouldleave this as 1.

MERGE specifyingYES here results inNMON_Analyser merging all of the input files to form a single file. The input files must be unsorted. By defaultthe Analyser will delete the TOP and UARG sections during the merge process;specify TOP to prevent this from happening but be aware that processing timewill be increased and that if the TOP section exceeds 65K lines then data willbe lost. Specify KEEP to stop the merged filefrom being deleted at the end of the run.Specify ONLY if you simply want tocreate a merged file for future analysis.

PIVOT specifyingYES here results inNMON_Analyser creating a Pivot Chartfrom the specified sheet after all other processing (includingprinting/publishing the other charts) has completed. See additional parameters on the “Settings”sheet.

ESS specifyingNO here results in NMON_Analyser bypassing the additional analysisperformed for ESS subsystems. This willresult in faster analysis and can allow larger files to be analysedsuccessfully when “out of memory” errors occur.

FILELIST the name ofa control file containing a list of nmon output files to be processed by theAnalyser. Leave this field blank fornormal operation. The name must be fullyqualified (e.g. c:\nmon\testcases\filenames.txt). The names specified inthe text file must contain full path information. Wildcard characters may be included in thefilenames so long as they conform to Windows standards. For example:

c:\nmon\testcases\*.nmon

NB: if you save the spreadsheet with a value in this field, the Analyser willautomatically begin execution the next time you open it. This is defined as “batch mode” (seeAppendix). You can stop the execution bypressing Ctrl+Break or by deleting/renaming the Control File.

NationalLanguage Settings

The following fields can be found on the“Settings” sheet.

SORTINP Change thisto NO if you use AIX (or the nmon2csv script) to pre-sort the file. This option is primarily useful in countrieswhere the Windows collating sequence sorts the string "AA" after"Z" (e.g. Denmarkand Norway).

Batch Processing Options

The following fields can be found on the“Settings” sheet.

REPROC Changethis to NO if you want to bypass processing of input files which may have beenprocessed in a previous run. This isuseful if you make use of wildcards in the batch control file. Note that the REPROC option only takes effectwhen you have specified more than one input file.

OUTDIR the name of an existing directory in whichoutput files will be saved by default. This is primarily intended for batchoperation (see FILELIST above) but also works to set thedefault directory for interactive sessions.If the directory does not exist (or OUTDIR is blank) then output filesare saved back to the same directory as the corresponding input files.

Example: C:\NMON\Analyser\Output\

Formatting Options

The following fields can be found on the“Settings” sheet.

BBBFont Enter thename of a fixed pitch font to be used for formatting the BBBC and BBBPsheets. Courierprovides acceptable results.

GWIDTH Change thevalues in this row to make the generated graphs bigger or smaller. The default value of 0 means that theAnalyser will dynamically size the graphs according to your screen size, fontsettings or page size. Be careful notto set a value larger than your page width when printing.

GHEIGHT Change the values inthis row to make the generated graphs bigger or smaller. If you specify a value here you must alsospecify a value for GWIDTH.

LIST Acomma-separated list a sheets for which the Analyser is to draw graphs. Only used if the GRAPHS option is set to LIST.

NOLIST The default isKEEP. If youchange this to DELETE then all sheets whichdo not appear in LIST will be deleted after analysis. This can dramatically reduce the size offiles that are to be kept for long periods.

REORDER specifying YES here results in NMON_Analyser reordering the sheets to improvenavigation to more relevant information.

TOPDISKS the maximumnumber of hdisks/vpaths to include on disk graphs. A value of 0 produces graphs containing allthe hdisks on a sheet (up to 250).Graphs containing more than 50 hdisks will be automatically scaled tofit and may therefore exceed the size of the screen.

xToD Format to be used for timestamps on Timeof Day graphs. Anything acceptable toExcel as a Number Format Code may beentered. Default is hh:mm.Note that the date is alsoavailable within the timestamp and you may therefore use something like dd-mmm-yy hh:mm if,for example, you have merged multiple NMON files together. If you use something other than the defaultstring you may need to increase the value of GHEIGHT – experiment withdifferent values if you don’t see what you expect.

Pivot Chart

These parameters are used to construct apivot chart. The required parametersare: Sheetname, PageField, RowField, ColumnField, DataField and xlFunction (canbe COUNT,SUM, MIN, AVG, MAX). This is primarily useful for the TOP andSUMMARY sheets but might prove useful for other, possibly user-supplied, datasheets.

Printing Options

The following fields can be found on the“Settings” sheet. Note - these only take effect if you select PRINT for theOUTPUT option on the Analyser sheet.

LSCAPE Change to YES if you wantthe Analyser to set the page orientation to Landscape. By default the Analyser will fit one chartper page when printing landscape.

COPIES Set tothe number of copies to be printed.

PRINTER The name ofthe printer. Specifying a value of PREVIEW willcause the Analyser to invoke the Excel print preview function - useful fortesting. You may also specify DEFAULT to printto the system default printer or the name of network printer.

The Analyser adds page headers andfooters.

Web Publishing Options

The following fields can be found on the“Settings” sheet.

PNG Changeto NO if your browser can’t handlethe PNG graphics format. Graphics willbe generated as GIF files.

SUBDIR If thisisYES thenall supporting files, such as background textures and graphics, areorganized in a separate folder. If this is NO then supporting files are saved in the same folder as the Web page.

WEBDIR the name of an existing directory in which HTMLfiles will be saved by default. If thedirectory does not exist (or OUTDIR is blank) then output files are saved backto the same directory as the corresponding input file.

Example: C:\NMON\Analyser\HTML\

Interpretingthe output sections

Noteson the “Weighted Average” as used in the Analyser

Several graphsproduced by the Analyser show average, weighted average and maximumvalues. Although everyone understandsaverages and maximums, the concept of a weighted average is a little moredifficult to grasp.

One of the problemswe are faced with in analysing sample data is that resources on the target systemmay be idle for long periods during the collection. For example, the NMON data collection may bestarted some time before the system reaches peak utilisation and may not bestopped until the workload being monitored has long since finished. Although this does not affect the maximumsit can severely affect the accuracy of the averages.

The idea of aweighted average is to apply a weighting factor to each snapshot to indicatehow relevant that snapshot is to the average.In NMON_Analyser, we use the value of the measurement itself as theweighting factor. In effect, thisproduces a figure that shows how busy a resource is when it is active. Forexample: a database log disk is onlyactive during the middle part of a benchmark.We record the following figures for %tm_act (DISKBUSY):

Snapshot	%tm_act
1	0
2	0
3	0
4	0
5	0
6	6.1
7	6.3
8	6.5
9	9.1
10	5.9
11	0
12	0
13	0
14	0
15	0

The average for this set of data is 2.3and the weighted average is 7.0. Theweighted average gives a better picture of how busy the disk is while loggingis taking place. NMON_Analyser uses theweighted average as a sort key when sorting the contents of disk sheets.

Note that, occasionally, NMON generatesvery large numbers for the first interval and this heavily skews the weightedaverage values. If you see this problemoccurring then change the value for theFIRST parameter to 2 in order to exclude the first interval completely. This is only a problem for AIX.

SYS_SUMM

This section is entirely generated by theAnalyser and contains a useful summary of data taken from other sheets. Note the the avg/max values for User%,Sys%, Wait% and Idle% are independent and will not add up to 100%. The CPU% column shows avg/max values for thesum of usr%+sys% during each interval.For micro-partitions, the values are shown as a percentage of theVirtual Processors – they do not relate to the CPU_ALL values.

For non-partitioned or dedicated CPUpartitions the graph shows the total CPU Utilisation (%usr + %sys) togetherwith the Disk I/O rate (taken from the DISKXFER sheet) by time of day. For micro-partitions the graph shows thenumber of physical CPUs being used instead of CPU%.

The value “Max:Avg” is simply the maximumvalue divided by the average. Ifmonitored over a long period of time the value for CPU% can be useful inspotting a system reaching saturation level (the ratio will steadilydecrease). If you have historical datathen the value can also be useful in determining how much latent demand ispresent in a system running at saturation level.

AAA

The AAA section is generated by NMON atthe start of the data collection and contains information about the system andNMON itself – contents vary by release, following is for 12e

AIX this is the release / maintenance level of AIX being used on thetarget system as reported by the lslpp command.

build theparticular build of nmon used to collect this data

command the commandline used to invoke NMON.

cpus the number of CPUs in the system and the number active at the startof data collection.

date date at the start of the collection.

disks_per_line the setting of the -l flag on the NMON command line or the default value.

hardware theprocessor technology used in the target system.

host the hostname of the target system.

Interval the time(in seconds) between snapshots.

kernel informationfrom the kernel - useful in identifying the type of kernel (32-bit or 64-bit)and whether this is an LPAR.

LPARNumberName the LPARnumber followed by the name

MachineType machine type andmodel of the system

progname the name ofthe NMON executable.

runname taken fromthe NMON command line if specified using the -r parameter, else defaults tohostname.

SerialNumber the machineserial number

snapshots the number of snapshots - this is used by the Analyser. The Analyser will modify this value to matchthe number of snapshots actually found in the input file.

subversion detailed information about the nmon version used to collect thisdata – including the date and time it was created.

time time as shown by the system clock at the start of the collection.

timestampsize the number ofcharacters used for timestamps in each record.The default is 5.

TL theTechnology Level of the AIX release

user the name of the user executing the NMON command.

version theversion of NMON used to collect this data.

VIOS therelease/maintenance level if this is aVIOS LPAR.

analyser theversion of NMON_Analyser used to generate the output file together with theelapsed time (in seconds) for processing this file.

environment the version ofExcel you are using.

parms the valuesof most of the user options specified onthe “Analyser” sheet.

settings thevalues of most of the user optionsspecified on the “Settings” sheet.

elapsed theexecution time of the Analyser. I usethis for tuning.

NMON_Analyser deletes the NOTES lines generated by NMON.

BBBB

The BBBB sheet lists all of the diskslisted in the ODM together with the capacity (in Gbytes) and the adapter type(SCSI/SSA/Fibre) as reported by lsdev. Note that some fibre-attacheddevices do not report their capacity to AIX.

NMON_Analyser deletes the columncontaining the sort key generated by NMON on all BBB sheets.

BBBC

The BBBC sheet shows the output from the lspv command forall local disks at the start of the data collection. The Analyser highlightsthe hdisk name using a bold font and sets the sheet to use the fixed-pitch fontspecified on the NLS sheet (default Courier) in order to improve readability.

BBBD

The BBBD sheet shows a list of all I/Oadapters listed in the ODM together with the hdisks addressed through thatadapter.

BBBE

The BBBE sheet contains data extractedfrom the lsdev command and shows the mapping between vpaths and hdisks. NMON_Analyser uses this information toconstruct the ESSBUSY, ESSRSIZE and ESSWSIZE sheets.

BBBG

The BBBG sheet contains details of theNMON disk group mappings.

BBBL

TheBBBL sheet is only produced if the operating system is running in a partitionsand contains details of the configuration of the LPAR at the start of thecollection run.

BBBN

TheBBBN describes each network adapter in the system and shows the name, speed andMTU size.

BBBP

The BBBP sheet contains theun-interpreted output from the emstat and lsattrcommands. Note that to get output fromthese commands requires NMON to be running with root privileges.

The Analyser sets the sheet to use thefixed-pitch font specified on the NLS sheet (default Courier) in order toimprove readability.

BBBR

This sheet records dynamic LPARreconfiguration events during the collection run.

BBBV

This sheet lists all of the volume groupspresent at the start of the collection run.

CPUnnn

These sheets show %usr, %sys, %wait and %idle by time of dayfor each logical processor. Note thatfor micropartitions the Idle% and Wait% figures will include times whenthe physical processor was ceded to the shared pool.

NMON_Analyser generates a graph and acolumn headed “CPU%” containing the sum of %usr and %sys for use on the CPU_SUMMsheet. The Analyser also adds blankintervals for CPUs that are varied online during the collection interval sothat the graphs cover the entire collection period.

If REORDER isset to YES on the Control sheet theAnalyser will move all CPUnn sheets to the end of the file.

CPU_ALL

This sheet shows the average utilisationfor all physical processors by time of day. Note that for micro-partitions CPU% is a measureof utilisation vs the entitlement but is adjusted by libperfstat so that itnever exceeds 100%; this makes the numbers virtually useless for analysis ofuncapped partitions and you may choose to look at the charts on the LPAR sheetinstead. Notealso that micro-partitions generally record very little Idle% or Wait% because theywill normally cede their timeslice to other LPARs rather than waste CPU timewaiting for work.

The second graph shows the number ofactive CPUs by time of day and is useful in determining whether CPUs have beenvaried on/off during the collection period.If the system has SMT enabled then the Analyser shows logical CPUsrather than physical CPUs and the legend reports “SMT=ON”.

CPU_SUMM

The Analyser generates this sheet fromdata on the CPUnnn sheets. It gives abreakdown of CPU Utilisation by thread (logical processor) and by core over thecollection period. The chart can bevery useful in identifying situations in which the system is thread-starved(i.e. too few threads to fully utilise the logical processors) or where theworkload is dominated by a small number ofsingle-threaded processes.

Note that if CPUs have been dynamicallyreconfigured during the collection period, these figures reflect only thoseintervals when the CPU was varied on.

General notes for DISK, ESS, EMC, FASt and DG sheets

The DISK sheets record device statisticsfor each hdisk in the system. If thereare more than <dpl> hdisks in the system (see "Collecting data using NMON"above) NMON generates multiple output sections. DISKBUSY will therefore contain device busystatistics for the first group of hdisks, DISKBUSY1 for the next, DISKBUSY2 forthe next and so on.

The Analyser will normally sort thecontents of the sheet in ascending sequence using the weighted average valuesas a sort key. However, if a storagesubsystem is detected then sorting of the DISK sheets is disabled and theESS/EMC/FASt/DG sheet contents are sorted instead.

If the number of hdisks (or vpaths) onthe sheet exceeds the value specified for TOPDISKS(see “Analyser options” above), the graph will only show information for thespecified number of disks and a warning will appear in the graph title.

If REORDER is set to YES on theControl sheet the Analyser will move all but the DISKBUSY, DISK_SUMM andDISKSERV sheets to the end of the file when a storage subsystem or Disk Groupis detected. The rationale behind thisbeing that the ESS/EMC/FASt/DG sheets contain the most useful data and that theDISK sheets merely replicate it.However, the DISKBUSY sheet is useful for checking the activity onsystem disks (normally local) and the DISK_SUMM sheet gives total data ratesfor the system (local + subsystem disks).

Note that NMON and NMON_Analyser can onlyhandle a maximum of 250 vpaths in a system.If you have more than this then you need to use the Disk Groups featureof NMON to select the vpaths that are of primary interest.

EMC/PowerPathsubsystems

NMON_Analyser detects the presence of anEMC/PowerPath subsystem by scanning the input file for the string “hdiskpower”before starting the analysis. EMCPowerPath creates devices called “hdiskpowern”which each map to multiple hdisks. Theyare therefore comparable to the vpaths generated by ESS/SDD. However, unlike vpaths, hdiskpower devicesappear to AIX (and, therefore NMON) as real disks and NMON therefore records theiractivity on the DISK sheets.

NMON_Analyser removes all hdiskpowerentries from DISK sheets and moves them to new sheets beginning with theletters EMC. For example, hdiskpowerentries found on DISKBUSY1 are simply moved to a new sheet called EMCBUSY1. If a DISK sheet contains only hdiskpowerdevices, that sheet is simply renamed.

All device statistics reported by theAnalyser (e.g. System I/O rates) are correct and as NMON excludes hdiskpoweractivity from the IOADAPT statistics these figures are also correct.

FAStTsubsystems

NMON_Analyserdetects the presence of a FAStT subsystem by scanning the input file for thestring “dac” before starting the analysis.They are handled in the same way as EMC/PowerPath subsystems except thatthe dac devices are moved to sheets with names beginning "FASt".

Notethat the Analyser is not able to correctly handle systems having both EMC andFASt subsystems.

DGBUSY

This sheet records theaverage value of device busy for each hdisk in the NMON Disk Group.

DGREAD

This sheet records theaverage data rate (Kbytes/sec) for read operations to each NMON Disk Group.

DGSIZE

This sheet records theaverage data transfer size (block size), in Kbytes, for read/write operationsto each NMON Disk Group.

DGWRITE

This sheet records theaverage data rate (Kbytes/sec) for write operations to each NMON Disk Group.

DGXFER

This sheet records the totalI/O operations per second to each NMON Disk Group.

DISKBSIZE

Thesesheets record the average data transfer size (block size), in Kbytes, forread/write operations on each hdisk in the system. If this number is not very close to thestripe size for the device there may be a problem that could be solved byincreasing the value of numclust.

DISKBUSY

These sheets record device busy for eachhdisk in the system. This is the same asthe %tm_act value recorded by iostat. Note that if this sheet contains all zerovalues then it means you forgot to enable iostat collection before startingnmon:

chdev -l sys0 -a iostat=true

DISKREAD

These sheets record the data rate(Kbytes/sec) for read operations on each hdisk in the system.

DISKSERV

These sheets record the service times (inmilliseconds) for read/write transfers to each hdisk in the system.

DISKWAIT

These sheets record the queue times (in milliseconds)for read/write transfers to each hdisk in the system.

DISKWRITE

These sheets record the data rate(Kbytes/sec) for write operations on each hdisk in the system.

DISKXFER

These sheets record the I/O operationsper second for each hdisk in the system.This is the same as the tps value recorded by iostat.

DISK_SUMM

The Analyser creates this sheet. It shows the total data rates (reads andwrites) in Kbytes/sec plus total I/O rates for all hdisks in the system. The figures on this sheet are accurate forall systems including ESS, EMC, FASt and HDS configurations.

These data are displayed on the chart; theIO/sec data are also graphically displayed on the AAA sheet.

DONATE

This sheet records physical processorusage and donation to the shared pool.Only present for dedicated LPARs running on POWER6systems.

EMCBSIZE/FAStBSIZE

This sheet records the average datatransfer size (blocksize), in Kbytes, for read/write operations to eachesoteric device in a system using EMC/PowerPath or FAStT.

EMCBUSY/FAStBUSY

These sheets record device busy for eachesoteric device in a system using EMC/PowerPath or FAStT.

EMCREAD/FAStREAD

These sheets record the data rate(Kbytes/sec) for read operations to each esoteric device in a system usingEMC/PowerPath or FAStT.

EMCWRITE/FAStWRITE

This sheet records the data rate(Kbytes/sec) for write operations to each esoteric device in a system usingEMC/PowerPath or FAStT.

EMCXFER/FAStXFER

These sheets record the I/O operationsper second to each esoteric device in a system using EMC/PowerPath or FAStT.

EMCSERV/FAStSERV

The Analyser creates this sheet. It shows estimated services times (notresponse times) for each esoteric device over the collection interval. The service time is derived from the devicebusy and the transfer rate taken from the corresponding BUSY and XFERsheets. Intervals where the transferrate is below SVCXLIM are ignored in orderto improve the accuracy of the estimate.

ERROR

This sheet shows all errors reported bynmon during the collection run.FIRST/LAST intervals are ignored for this sheet. Timestamps are not converted to time values.

ESSBSIZE

This sheet is only present if ESS is set to YES and recordsthe average data transfer size (blocksize), in Kbytes, for read/write operationson each vpath in the system. The data on this sheet are calculated byNMON_Analyser as the average of the DISKBSIZE values for component hdisks asrecorded on the BBBE sheet.

ESSBUSY

This sheet is only present if ESS is set to YES and records devicebusy for each vpath in a system using ESS.The data on this sheet are calculated by NMON_Analyser as the average ofthe DISKBUSY values for component hdisks as recorded on the BBBE sheet.

ESSREAD

This sheet records the data rate(Kbytes/sec) for read operations on each vpath in the system. This information is provided by NMON.

ESSWRITE

This sheet records the data rate(Kbytes/sec) for write operations on each vpath in the system. This information is provided by NMON.

ESSXFER

These sheets record the I/O operationsper second for each vpath in the system.This information is provided by NMON.

FCREAD

This sheet records the data rate(MBytes/sec) for read operations on each Fibre Channel adapter in thesystem.

FCWRITE

This sheet records the data rate (MBytes/sec)for write operations on each Fibre Channel adapter in the system.

FCXFERIN

This sheet records the read operationsper second for each Fibre Channel adapter in the system.

FCXFEROUT

This sheet records the write operationsper second for each Fibre Channel adapter in the system.

FILE

This sheet contains a subset of thefields reported by NMON on the Kernel Internal Statistics panel. These are the same values as reported by thesarcommand.

All fields are rates/sec.

iget translations of i-node numbers to pointers to the i-node structureof a file or device.This is reported as iget/s by the sar -a command. Calls to iget occur when a call to to namei has failed tofind a pointer in the i-node cache. This figure should therefore be as close to0 as possible.

namei callsto the directory search routine that finds the address of a v-node given a pathname. This is reported as lookuppn/s by the sar -a command.

dirblk numberof 512-byte blocks read by the directory search routine to locate a directoryentry for a specific file. This is reported as dirblk/s bythe sar -a command.

readch characterstransferred by read system call. This is reported as rchar/s by the sar -c command

writech characterstransferred by write system call. This is reported as wchar/s by the sar -c command.

ttyrawch tty inputqueue characters. This is reported as rawch/s by the sar -y command.

ttycanch ttycanonical input queue characters. This field is always 0 (zero) for AIX Version4 and later versions.

ttyoutch ttyoutput queue characters. This is reported as outch/s bythe sar -y command

NMON_Analyser produces two graphs - oneshowing rates/sec for readch and writech by time of day and one showing rates/sec for iget, namei and dirblk.

FRCA

This sheet is only generated if FRCA isloaded on the target system. NMON_Analyser produces a graph showing the cachehit ratio (as a percentage). If FRCA isnot loaded, NMON generates no data and the Analyser consigns the redundantheader record to the StrayLines sheet.

IOADAPT

For each I/O adapter listed on the BBBCsheet, contains the data rates for both read and write operations (Kbytes/sec)and total number of I/O operations performed. On AIX 5.1 and later, thisinformation is reported by the iostat-A command. NMON_Analyser reorders the columns on thesheet for easier graphing.

The Analyser generates three graphs. Note the area charts can be easily convertedto line charts if required. Simplyright click on the white space within the chart area, then select ChartType>Line>OK.

IP

This sheet only appears for topasout.

JFSFILE

For each file system, this sheet showswhat percentage of the space allocation is being used during eachinterval. These figures are the same asthe %Used value reported by the dfcommand. The column headings show the mount point;sheet BBBC can be used to cross-reference to the file system/LV.

JFSINODE

For each file system, this sheet showswhat percentage of the Inode allocation is being used during eachinterval. These figures are the same asthe %Iused value reported by the df command. The column headings show the mountpoint; sheet BBBC can be used to cross-reference to the file system/LV.

LAN

This sheet only appears for topasout.

LARGEPAGE

The graph shows Usedpages and Freepagesover time.

Columns on the sheet are as follows:

Freepages thenumber of large pages on the free list.

Usedpages thenumber of large pages currently in use.

Pages the number of large pages in the pool.

HighWater themaximum number of pages used since the last reboot.

SizeMB the size of a large page in Mbytes.

LPAR

Thefirst graph shows the number of physicalprocessors used by this partition vs the entitlement. For an uncapped partition the number ofphysical processors may exceed the entitlement but can never exceed the number of virtualprocessors allocated to the partition. ForAIX the graph also shows the number of unfolded virtual processors (AIX will“fold” - stop dispatching work to - excess processors in order to minimisescheduling costs).

Notethat the ratio of physical processor to entitlement (shown as %entcin the output of the lparstat command) will generally be higherthan CPU% on the CPU_ALL sheet. The reason for this is that a partition thatis within its entitlement may wait for a short period of time before ceding aprocessor that enters an I/O wait or becomes idle. This can eliminate unnecessary contextswitches.

Thesecond graph shows CPU utilisation as a percentage of virtual processors – forAIX this is broken down in to usr%, sys% and wait%. This level of detail is not available forLinux or releases of NMON prior to version 12.

Thethird graph is only present for AIX systems and shows cpu utilisation of theshared pool by this and other partitions.The area marked “UsedPoolCPU%” represents the percentage of the sharedpool that has been used by this partition, while the area marked “other% “represents the percentage used by all other partitions. Note that if the partition is not authorisedto see utilisation of the shared pool then the pool will appear to be 100%utilised.

Columnson the sheet are as follows:

PhysicalCPU physical cores consumed by AIX

VirtualCPUs numberof Virtual CPUs allocated to the LPAR

logicalCPUs number ofthreads (i.e.Virtual CPUs multiplied by SMTmode)

poolCPUs number of cores in the pool thatthis LPAR occupies

entitled the number of cores guaranteedto be available to this LPAR

weight the priority of this LPAR whencompeting for unused CPU cycles

PoolIdle the number of unusedcores in the Pool

usedAllCPU% percentage of active cores in the machine that this LPAR isusing

usedPoolCPU percentage of cores in the pool that this LPAR is using

SharedCPU 1 if the LPAR is not a dedicated CPU

Capped 1 if the LPAR is capped

EC_User% percentage of Entitlement used in User mode

EC_Sys% percentage of Entitlement used in System mode

EC_Wait% percentage of Entitlement waiting for I/O

EC_Idle% percentage of Entitlement used in Idle mode

VP_User% percentage of Virtual CPU used in User mode

VP_Sys% percentage of Virtual CPU used in System mode

VP_Wait% percentage of Virtual CPU waiting for I/O

VP_Idle% percentage of Virtual CPU spent in Idle mode

Folded no. of Virtual CPUs unused for efficiency reasons

CPU_Pool_id theId of the CPU pool, useful if there are multiple pools

MEM

The main graph on this sheet shows theamount of Real Free memory in Mbytes by time of day. This would be the same as dividing the fre values reported by vmstat over the same interval by 256. The small graph shows the amount ofreal memory. This is useful in determining if dynamic reconfiguration has beenused during the collection period.

For AIX, other columns on the sheet areas follows:

RealFree the percentage of real pages on the free list.

VirtualFree the percentage of unallocated virtual slots on the paging spaces.

RealFree (MB) the amount of memory on the free list in Mbytes.

VirtualFree (MB) theamount of unallocated space on the paging spaces.

RealTotal (MB) the total amount of memory available to AIX.

VirtualTotal (MB) thetotal amount of space allocated for paging spaces.

Note: you can calculate the amount ofmemory used during an interval simply by subtracting the RealFree (MB) valuefrom the RealTotal (MB) value.This will, however, include filepages. The graph on the MEMUSE sheetgives a more accurate assessment of memory used by programs (computationalpages).

MEMUSE

Except for %comp, thevalues on this sheet are the same as would be reported by the vmtune command.

%numperm the percentageof real memory allocated to file pages.

%minperm valuespecified on the vmtune command or system default of 20%. This will normally be constantfor the run unless the vmtune or rmss commands are used during collection.

%maxperm valuespecified on the vmtune command or system default of 80%. This will normally be constantfor the run unless the vmtune or rmss commands are used during collection.

minfree theminimum number of pages AIX is to keep on the free list. Specified on the vmtune command or systemdefault of maxfree - 8.

maxfree themaximum number of pages AIX is steal in order to replenish the free list. Specified on the vmtune command or systemdefault.

%comp Thepercentage of real memory allocated to computational pages. NMON_Analysercalculates this value. Computationalpages are those backed by page space and include working storage and programtext segments. They exclude data, executableand shared library files.

The Analyser generates two graphs. The first shows the split betweencomputational and file pages by time of day.The second plots the values of %numperm, %minperm, %maxperm and %comp.

If %numpermfalls below %minperm then computationalpages will be stolen. If %numperm rises above %maxperm then computationalpages cannot be stolen. Low values forboth %minperm and %maxperm indicate that the system has been tuned for a database server. You may also want to check the setting of STRICT_MAXPERM onthe BBBP sheet (if present).

MEMNEW

The graph shows the allocation of memorysplit into the three major categories: pages used by user processes, filesystem cache, and pages used by the system (kernel).

Process% thepercentage of real memory allocated to user processes

FSCache% thepercentage of real memory allocated to file system cache

System% the percentage of real memory used by system segments

Free% the percentage of unallocated real memory

User% the percentage of real memory used by non-system segments

MEMPAGES4K/64K/16MB/16GB

Thesesheets are only present for AIX. Theyshow various statistics for different page sizes in use within the system. The Analyser will delete the sheets for pages sizes notcurrently in use.

Forthe MEMPAGES64KB sheet a graph is drawn showing the use of both 4KB and 64KB pages within the system –starting with AIX V6.1 (and supporting hardware) these page sizes are selecteddynamically based on memory access patterns.

MEMREAL

Thissheet only appears for topasout. The Analyser adds a column showing Real Freememory in Mbytes.

MEMVIRT

Thissheet only appears for topasout.

NET

This sheet shows the data rates, inKbytes/sec, for each network adapter in the system (including SP switch ifpresent). This is the same as producedby the netpmon –O dd command. NMON_Analyser addsone column for each adapter showing the total data rate (read + write) and twocolumns showing Total Read and Total Write.Note that the Total Write is calculated as a negative number forgraphing.

The Analyser generates three graphs. The first graph shows total network trafficbroken down as Total-Read and Total-Write.The writes are shown below the X-Axis.

Note the area chart can be easilyconverted to a line chart if required.Simply right click on the white space within the chart area, then selectChart Type>Line>OK.

NETPACKET

This sheet shows the number of read/writenetwork packets for each adapter. This is the same as produced by the netpmon –O ddcommand.

NETSIZE

Thissheet shows the average packet size in bytes for each network adapter in thesystem.

NFS sheets

Thereare separate sheets for NFS2, NFS3 and NF4 client/server. The Analyser will delete empty sheets.

PAGE

This sheet has the paging statistics asrecorded by NMON.

faults thenumber of page faults per second. This is not a count of page faults thatgenerate I/O, because some page faults can be resolved without I/O.

pgin the total rate/sec of page-in operations to both paging space andfile systems during the interval.

pgout thetotal rate/sec of page-out operations to both paging space and file systemsduring the interval.

pgsin therate/sec of page-in operations from paging space during the interval. This is the same as the pi value reported by vmstat. If pgsin is consistently higherthan pgsout this may indicatethrashing.

pgsout therate/sec of page-out operations to paging space during the interval. This isthe same as the po value reported by vmstat.

reclaims from NMON 10 onwards this field is the same as the fr value reported by vmstat and representsthe numberof pages/sec freed by the page-replacement routine.

scans thenumber of pages/sec examined by the page replacement routine. This is the same as the sr value reported by vmstat. Page replacement is initiated when the number of free pages fallsbelow minfree and stops when thenumber of free pages exceeds maxfree.

cycles thenumber of times/sec the page replacement routine had to scan the entire PageFrame Table in order to replenish the free list. This is the same as the cy value reported by vmstat but note that vmstat reports this number as an integer whereas nmon reports it as a realnumber.

fsin calculated by the Analyser as pgin-pgsin for graphing

fsout calculated by the Analyser as pgout-pgsout for graphing

sr/fr calculated by the Analyser as scans/reclaims for graphing

NMON_Analyser produces two graphs. The first shows paging operations to/frompaging space. The ideal here would be nomore than 5 operations/sec per page space (see the BBBC sheet for details). The second graph shows the scan:freerate. Memory may be over-committed whenthis figure is >4 although you also need to examine the MEM and PAGE sheetsas well.

POOLS

Thissheet contains information about the shared pool in which the LPAR isrunning. Most of the data will only bepresent if “Allow performance information collection.” is set in the LPARproperties.

shcpus_in_sys the number of coresallocated to the global shared pool

max_pool_capacity the maximumnumber of VPs defined for this pool

entitled_pool_capacity the entitlementfor this pool (includes reserve entitlement)

pool_max_time same as max_pool_capacity but may vary in value if the pool definition is changed during thecollection run.

pool_busy_time the average number of cores in use by this shared pool during theinterval

shcpu_tot_time the average number of cores available to the global shared pool(including shared dedicated resources?) during the interval

shcpu_busy_time the average number of core in use within the global shared pool

pool_id this identifierof this pool

entitled the entitlementof this LPAR

PROC

This sheet contains a subset of thefields reported by NMON on the Kernel Internal Statistics panel. The RunQueueand Swap-in fields are averagevalues for the interval. All other fields are rates/sec:

RunQueue the averagenumber of kernel threads in the run queue. This is reported as runq-sz by the sar -q command and is reported as RunQueue onthe nmon Kernel Internal Statistics panel.A value that exceeds 3x the number of CPUs may indicate CPU constraint.

Swap-in theaverage number of kernel threads waiting to be paged in. This is reported as swpq-sz by the sar -q command.

pswitch thenumber of context switches. This is reported as pswch/s bythe sar -w command.

syscall thetotal number of system calls. This is reported as scall/s bythe sar -c command.

read the number of read system calls. This is reported as sread/s reported by the sar-c command.

write the number of write system calls. This is reported as swrit/s by the sar -c command.

fork the number of fork system calls. This is reported as fork/s by the sar -c command.

exec the number of exec system calls. This is reported as exec/s by the sar -c command.

rcvint thenumber of tty receive interrupts. This is reported as revin/s by the sar -y command.

xmtint thenumber of tty transmit interrupts. This is reported as xmtin/s by the sar -y command.

sem the number of IPC semaphore primitives (creating, using anddestroying). This is reported as sema/s by the sar -m command.

msg the number of IPC message primitives (sending and receiving). Thisis reported as msg/s by the sar -m command.

NMON_Analyser produces three graphs - oneshowing the average length of the RunQueue andthe number of swap-ins by time of day,another showing rates/sec for pswitch and syscalls by time of day and a third showing rates/sec for forks and execs.

The graph for forks/execs can be usefulwhen monitoring web server systems.

PROCAIO

Thissheet contains information about the number of asynchronous I/O processesavailable and active (i.e. using more than 0.1% of the CPU) . It also shows the amount of CPU being usedby the AIO processes during the collection interval.

Twographs are produced. The second usestwo y-axes. The number of running aioprocesses is shown against the first axis and the amount of cpu used is shownagainst the second.

RAWCPUTOTAL, RAWLPAR

Thesesheets contain a dump of various counters such as context switches and phantominterrupts.

TCPUDP

Thissheet only appears for topasout.

TOP

This sheet is only generated if youspecify the -t flag on the NMON commandline. The output is similar to thatproduced using the ps v command. Note that, becauseof the limitation of having only 65,000 lines on a single sheet, some data maybe omitted for very large files and this may mean that entire PIDs or evencommands may be missing from the analysis.

Note that data are only present forprocesses that consumed a significant amount of CPU during an interval. The TOP sheet does not represent a completeview of the system.

NMON_Analyser does the following:

reorders the columns for easier processing.

Sorts the data on the sheet into COMMAND name order - using TIME as aminor sort key.

Creates a table at the end of the sheet summarising the data bycommand name and used for graphing.

You can see the detail section byscrolling to the top of the sheet. Thesummary table is largely obscured by the graphs and so you will need to move(or delete) them for easier viewing.

PID in the detail section this is the process ID of a specificinvocation of a command. In the summarytable this is the command name.

%CPU inthe detail section this is the utilisation of a single processor (rather thanof the system) by that PID during the interval. In the summary table this isthe average amount of CPU used by all invocations of the command during thecollection period.

%Usr in the detail section this is the average amount of User-mode CPUused by that PID during the interval.

%Sys in the detail section this is the average amount of Kernel-mode CPUused by that PID during the interval.

Threads the number of (software) threads being used by this command.

Size the average amount of paging space (in Kbytes) allocated for thedata section (private segment + shared library data pages) for one invocationof this command. This is the same as theSIZE figure on the ps v command. Note that if Size is greaterthan ResData it means some working segment pages are currently paged out.

ResText the average amount of real memory (in Kbytes) used for the codesegments of one invocation of this command.Note that multiple concurrent invocations will normally share thesepages.

ResData the average amount of real memory (in Kbytes) used for the datasegments of one invocation of this command.A method of calculating real memory usage for a command is ResText + (ResData * N).

CharIO this is the count of bytes/sec being passed via the read and writesystem calls. The bulk of this is reading and writing to disks but alsoincludes data to/from terminals, sockets and pipes. Use this to work out whichprocesses are doing the I/O.

%RAM this is an indication of what percentage of real memory this commandis using. This is (ResText +ResData) / Real Mem; it is the same as the %MEM value on the

ps v command. Due torounding/truncation, and the large amounts of memory in modern systems, this isusually 0.

Paging sum of all page faults for this process. Use this to identify which process is causingpaging but note that the figure includes asynchronous I/O and can be misleading.

Command name of the command

WLMClass name of the Workload Partition or Workload Manager superclass towhich this command has been allocated (64-bit kernel only).

IntervalCPU generated by the Analyser.In the detail section this shows the total amount of CPU used by allinvocations of a command in the time interval.It is calculated as the sum of CPU used by all PIDS running the samecommand divided by the number of active processors (physical cores) availableduring the interval. In the summary section this is broken down as Average,Weighted Average and Maximum and is used to generate the graph.

WSet generated by the Analyser.In the detail section this shows the total amount of memory used by allinvocations of a command recorded in the time interval. It is calculated as ResText + (ResData * N) (where “N” isthe number of copies of this command running concurrently during the interval).In the summary section this is brokendown as Minimum, Average and Maximum and is used to generate the graph.

User generated by the Analyser if a UARG sheet is present. This contains the name of the user runningthe process.

Arg generated by the Analyser if a UARG sheet is present. This contains the complete argument stringentered for the command.

TheAnalyser generates four graphs using data in the generated table:

A graph showing Average,Weighted Average and Maximum CPU Utilisation by command

A graph showing Minimum,Average and Maximum Memory Utilisation by command

A graph showing Average,Weighted Average and Maximum CHARIO by command

A graph showing the CPUutilisation for each PID for each interval as a scatter chart. Note that this chart is only produced ifthere are fewer than 32,000 lines on the TOP sheet. See below for notes oninterpreting this chart.

Interpreting the %Processor by PID chart

Thepurpose of the chart is to provide a link to the UARG sheet so that you candiscover precisely which invocation of a command was responsible for using theCPU. It shows the processor utilisation (utilisation of a single CPU) by eachPID captured on the TOP sheet. Note thata process can use more than 100% of a single CPU if it is multi-threaded.

ActivePIDs will create a cluster of points on the chart. The highest point will show the maximumamount of CPU used during any one snapshot.To find out which PID a point refers to, move the mouse to position thecursor above it and Excel will display a coordinate pair. The first coordinate is the PID – use thisto refer to the UARG sheet to find precisely which command was being executed.

UARG

Thissheet has the first 1,000 commands executed during the collection period. The commands are listed in time order. Note that commands appearing in the firstinterval may have been executing prior to the start of the collection.

PID the process ID of a specific invocation of a command

PPID the parent process ID

COMM the command being executed

THCOUNT the number of threads started by this process

USER the name of the user running this process

GROUP the name of the group to which the user belongs

FullCommand the full command stringentered by the user

VM

This sheet is only presentfor Linux systems and contains a dump of the /proc/vmstat file values.

The two graphs showsfile-backed paging (pgpgin/pgpgout) and swap space activity.

WPAR sheets

Thesesheets are only present for AIX V6 and record data for each Workload Partitionin the system. They are not currentlygenerated by the topas version of nmon.

WLM sheets

Containdetails of CPU, Memory and I/O bandwidth used by each Superclass/Subclassdefined to WLM during the collection run.The Analyser will extract subclasss data and create a new set of sheetsfor each class with more than one subclass.These sheets will be named “WLMCPU.class” etc.

Ifthis is a Micro-partition then the Analyser will also create a set of WLMPCPUsheets which will show the physical processor utilisation rather than %CPUutilisation.

ZZZZ

The Analyser uses the information on thissheet to automatically convert all NMON time stamps to actual time of day foreasier analysis. For NMON10 or later a column is added which contains the dateand time as a single value and this is used for the conversions. The number of rows on this sheet is used bythe Analyser to reset the “snapshots” value on the AAA sheet in case the nmonrun was terminated with SIGUSR2.

Error Handling

Error handlingin NMON_Analyser is rudimentary. The Analyser can handle many input file errors, but occasionally theanalysis will halt leaving you staring at a dialog box. Should this happen, please accept myapologies. However, before sending me acopy of the input file, please read the following:

Common problems

The most commonly reported problems arisefrom invalid input files. We also getproblems reported where, for whatever reason, lines have been truncated, splitor even duplicated. NMON_Analyserattempts to trap these errors and will report them on the “StrayLines”sheet. Check this sheet if the run stopsunexpectedly.

'No valid input! NMON run may have failed.'

The most common cause of this message isthat the NMON run failed and there really is no valid input. NMON initialises the output file by writingall of the section headings. If itsubsequently fails, you will get an output file that consists purely ofheadings - with no data. Check the file by loading it into a wordprocessor or, indeed, a spreadsheet (as a .csv file) before you send it to me.

'Unexpected end offile.'

This is only reported when processingfiles >65K lines and when SORTINP is set to NO. It is usually caused by the fact that lines are being terminated with a CR character insteadof CRLF. Change your FTP option toASCII or TEXT when sending the file toyour PC. This problem only shows up withfiles of >65K lines because the Analyser uses a different technique to readlarge files from that used to read smaller files.

Strangely, one of the most commonproblems I get is caused by the fact that the Analyser can’t handle files witha single data interval very well. Ifyou want to test the package just let NMON run for a few minutes to get areasonable data sample!

Known bugs/problems (V3.3, topas_nmon)

When analysing systems with a very large number of disks, Excel canstop with error “No more fonts can be added”.Set GRAPHS to LIST and manually select which sheets to have graphs drawn on.

The PIVOT option does not seem to work with Excel 2007

The Analyser will crash if you edit the .csv file using Excel priorto the run and the file contains a TOP section. If you need to edit the input file, use aword processor.

There are some issues with processing files from systems having bothESS and EMC subsystems attached. Testcases welcomed.

When analysing ESS subsystems with more than 253 vpaths some vpathdata will be missing from the output.Use NMON Disk Groups to combine several vpaths into a single unit forreporting and use the –E flag to prevent the ESS sections from being produced. Alternatively, set ESS to NO on the Controlsheet and ignore warning messages about data truncation – only the first 253vpaths will appear in the output.

How to report a problem

Send a copy of the original,unmodified .nmon input file, plus the incomplete output spreadsheet, in acompressed (zipped) file to StephenAtkins/UK/IBM orsteve_atkins@uk.ibm.com together with a description of any dialogs you saw or a descriptionof where you think the problem lies.Please make sure you compress the files.I often work at home and, although I have broadband, unnecessarily largefiles are still an irritant.

If you have the ability to capture ascreenshot then a copy of any dialog boxes also proves useful on occasion.

Note: Development is currently done on Microsoft Excel 2003 (11.8320.8221)SP3. I may not be able to fix problemsarising from the use of different releases.

Excel/VBA Resources/Links

This is a good source for Excel tips andit has some VBA examples as well:

http://exceltips.vitalnews.com/

This is the home of an excellentreference book:

http://www.exceltip.com/

And of course

http://www.microsoft.com

Appendix: Notes on Batch Operation

If you regularly process large numbers offiles, the operation of NMON_Analyser can be completely automated. Simply create a text file containing a listof nmon file names (using wild card characters as appropriate) and enter thename of this file into the FILELIST field of the Analyser control sheet. Specify the name of an existing directoryin the OUTDIR field if you want all of the output files to end up in one place. Save the NMON_Analyser spreadsheet under a newname (this is recommended so that you can still use NMON_Analyser forinteractive sessions).

Now create Windows .bat files to invokeExcel (see the samples below).

After processing the last input file, theAnalyser will automatically close down Excel.Note, however, that this only happens if you load a copy of the Analyserthat has a saved FILELIST name and if there are no other openspreadsheets. This allows you to usethe FILELIST option safely during an interactive session.

Sample .bat files

These sample batch control files aredesigned to use the pscp file from the PuTTY suite written and maintained bySimon Tatham at http://www.chiark.greenend.org.uk/~sgtatham/putty/

My thanks to Jamie Dennis for providingthem.