OBJSTAT parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (1 revision)
 
 
(12 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Template:OBJSTAT parameter subtitle}}
==Summary==
==Summary==
<dl>
<dl>
Line 10: Line 11:
<dd>[[Janus SOAP]]
<dd>[[Janus SOAP]]
<dt>Introduced
<dt>Introduced
<dd>[[Sirius Mods]] 6.7
<dd><var class="product">[[Sirius Mods]]</var> 6.7
</dl>
</dl>
==Description==
==Description==
This bitmask parameter controls the display of journal messages that contain
This bitmask parameter controls the display of journal messages that contain
user statistics about [[Janus SOAP ULI]] object usage per request.
user statistics about <var class="product">SOUL</var> object usage per request.
The messages specify server table usage (VTBL and STBL) and object-swapping counts
The messages specify server table usage (VTBL and STBL) and object-swapping counts
per object class and summed for all classes.
per object class and summed for all classes.


The meanings of the bits in the OBJSTAT parameter are:
The meanings of the bits in the <var>OBJSTAT</var> parameter are:
<dl>
<dl>
<dt>X'01'
<dt>X'01'
Line 24: Line 25:
<dt>X'02'
<dt>X'02'
<dd>Display post-evaluation object statistics to the journal.
<dd>Display post-evaluation object statistics to the journal.
<dt>X'10'
<dt>X'10'
<dd>Display post-compilation object statistics to both the terminal
<dd>Display post-compilation object statistics to both the terminal
Line 29: Line 31:
If this bit is on, it doesn't matter whether the X'01' bit is on or off &mdash;
If this bit is on, it doesn't matter whether the X'01' bit is on or off &mdash;
post-compilation statistics will still go to the journal.
post-compilation statistics will still go to the journal.
<dt>X'20'
<dt>X'20'
<dd>Display post-evaluation object statistics to both the terminal
<dd>Display post-evaluation object statistics to both the terminal
Line 36: Line 39:
</dl>
</dl>


The layout for the OBJSTAT messages is:
The layout for the <var>OBJSTAT</var> messages is:
<ul>
<ul>
<li>One message for each class of objects in the program, with this format:
<li>One message for each class of objects in the program, with this format:
<p>
<p class="syntax"><span class="literal">MSIR.0884: OBJECT</span> <span class="term">classname</span><span class="literal">: objects/VTBL/STBL -</span> <span class="term">x/y/z,</span> <span class="literal">count/pages swapped</span> <span class="term">a/b</span> </p>
&nbsp;&nbsp;MSIR.0884: OBJECT <i>classname</i>: objects/VTBL/STBL - <i>x/</i><i>y/</i><i>z</i>,
 
              count/pages swapped  <i>a/</i><i>b</i>
</P>
<li>A single message that reports the sum of the counts of the
<li>A single message that reports the sum of the counts of the
preceding individual classes, with this format:
preceding individual classes, with this format:
<p>
<p class="syntax"><span class="literal">MSIR.0884: *TOTAL*: objects/VTBL/STBL -</span> <span class="term">x/y/z,</span> <span class="literal">count/pages swapped</span> <span class="term">a/b</span> </p>
&nbsp;&nbsp;MSIR.0884: *TOTAL*: objects/VTBL/STBL - <i>x/</i><i>y/</i><i>z</i>,
              count/pages swapped  <i>a/</i><i>b</i>
 
</ul>
</ul>


</p>
Where:
Where:
<dl>
<table>
<dt>classname
<tr><th>classname</th>
<dd>Identifies the name of the class for which space for object instances is allocated.
<td>Identifies the name of the class for which space for object instances is allocated.
Sirius system classes are prefixed with ''''SYSTEM:''''
Sirius system classes are prefixed with <code>SYSTEM:</code> or <code>COLLECTION:</code>, as applies.
or ''''COLLECTION:'''', as applies.
Sirius enumerations are excluded because they do not take up server space outside
Sirius enumerations are excluded because they do not take up server space outside
of what is used for the enumeration variables themselves.
of what is used for the enumeration variables themselves. </td></tr>
<dt>x
 
<dd>The number of object instances for which server space is allocated for the
<tr><th>x</th>
<td>The number of object instances for which server space is allocated for the
indicated class for the request.
indicated class for the request.
Note that this is different from the number of object variables in a request.
Note that this is different from the number of object variables in a request.
Line 67: Line 64:
relatively small) and number at compile time.
relatively small) and number at compile time.
The actual objects, on the other hand, can be quite large, and they can often have
The actual objects, on the other hand, can be quite large, and they can often have
a very large number of instances created at evaluation time.
a very large number of instances created at evaluation time.  
<p>
Unless a <code>Sirius</code> compiler directive is specified, this number reflects
the number of objects that <var class="product">SOUL</var> has determined is the minimum required.
Server and, in some cases for system classes, space might be required for three
or four objects. </p></td></tr>


Unless a ''''Sirius'''' compiler directive is specified, this number reflects
<tr><th>y</th>
the number of objects that [[Janus SOAP ULI]] has determined is the minimum required.
<td>The VTBL units (32 bytes per unit) occupied by the allocated object instances.
Server and, in some cases for system classes, space might be required for three
or four objects.
<dt>y
<dd>The VTBL units (32 bytes per unit) occupied by the allocated object instances.
Each instance of an object in a given class requires the same amount of space:
Each instance of an object in a given class requires the same amount of space:
a fixed
a fixed amount for an object header, and a non-fixed amount for each member variable
amount for an object header, and a non-fixed amount for each member variable
(that is, every variable in the <var>Public</var> or <var>Private</var> &mdash; but not <var>Public Shared</var> or
(that is, every variable in the Public or Private &mdash; but not Public Shared or
<var>Private Shared</var> &mdash; blocks).
Private Shared &mdash; blocks).
<p>
 
The VTBL units reported here do '''not''' include the VTBL space
The VTBL units reported here do '''not''' include the VTBL space
that is occupied by each local object reference in the main program routine.
that is occupied by each local object reference in the main program routine.
These references include object variables in declarations
These references include object variables in declarations
(including method parameter declarations and explicit and implicit method objects)
(including method parameter declarations and explicit and implicit method objects)
and &ldquo;work&rdquo; object variables.
and "work" object variables.
These work variables are used to hold intermediate results in the evaluation of
These work variables are used to hold intermediate results in the evaluation of
statements containing method concatenations.
statements containing method concatenations.
They may be reused within the class, and they typically do not add significantly
They may be reused within the class, and they typically do not add significantly to the VTBL space used.
to the VTBL space used.
Object references use 2 VTBL units each, excepting <var>XmlNode</var> objects, which use approximately 8. </p></td></tr>
Object references use 2 VTBL units each, excepting XmlNodes, which use
 
approximately 8.
<tr><th>a</th>
<dt>a
<td>The number of object swaps.
<dd>The number of object swaps.
This is the number of times objects of this class were swapped into or out of the server during the request.
This is the number of times objects of this class were swapped into or out of
the server during the request.
A swap out counts as one, and a swap in as one, so a swap in and out counts as two.
A swap out counts as one, and a swap in as one, so a swap in and out counts as two.
Accessing a global/session object counts as a swap in, since objects do not stay in the
Accessing a global/session object counts as a swap in, since objects do not stay in the
server between requests, so they need to be swapped into/out of CCATEMP.
server between requests, so they need to be swapped into/out of CCATEMP.
<p>
Swaps happen only during evaluation, so this number should always be zero in the post-compilation statistics. </p></td></tr>
<tr><th>b</th>
<td>The number of 6144-byte pages swapped into or out of the server.
This number should always be an integral multiple of <code>count</code>, and the multiplier should be one, except for very large objects (greater than 6144 bytes). </td></tr>
</table>


Swaps happen only during evaluation, so this number should always be zero
in the post-compilation statistics.
<dt>b
<dd>The number of 6144-byte pages swapped into or out of the server.
This number should always be an integral multiple of ''''count'''',
and the multiplier
should be one, except for very large objects (greater than 6144 bytes).
</dl>
The following is an example of typical post-compilation OBJSTAT output:
The following is an example of typical post-compilation OBJSTAT output:
<pre>
<p class="code">MSIR.0884: OBJECT LONG: objects/VTBL/STBL - 2/7/0, count/pages swapped 0/0
    MSIR.0884: OBJECT LONG: objects/VTBL/STBL - 2/7/0, count/pages
MSIR.0884: OBJECT PT: objects/VTBL/STBL - 2/18/0, count/pages swapped 0/0
                swapped 0/0
MSIR.0884: OBJECT CELL: objects/VTBL/STBL - 2/20/0, count/pages swapped 0/0
    MSIR.0884: OBJECT PT: objects/VTBL/STBL - 2/18/0, count/pages
MSIR.0884: OBJECT BOX: objects/VTBL/STBL - 2/75/144, count/pages swapped 0/0
                swapped 0/0
MSIR.0884: COLLECTION SYSTEM:ARRAYLIST OF OBJECT PT: objects/VTBL/STBL - 3/25/0, count/pages swapped 0/0
    MSIR.0884: OBJECT CELL: objects/VTBL/STBL - 2/20/0, count/pages
MSIR.0884: OBJECT SYSTEM:STRINGLIST: objects/VTBL/STBL - 3/18/0, count/pages swapped 0/0
                swapped 0/0
MSIR.0884: *TOTAL*: objects/VTBL/STBL - 14/163/144, count/pages swapped 0/0
    MSIR.0884: OBJECT BOX: objects/VTBL/STBL - 2/75/144, count/pages
</p>
                swapped 0/0
 
    MSIR.0884: COLLECTION SYSTEM:ARRAYLIST OF OBJECT PT:
                objects/VTBL/STBL - 3/25/0, count/pages swapped 0/0
    MSIR.0884: OBJECT SYSTEM:STRINGLIST: objects/VTBL/STBL - 3/18/0,
                count/pages swapped 0/0
    MSIR.0884: *TOTAL*: objects/VTBL/STBL - 14/163/144, count/pages
                swapped 0/0
</pre>
And the following is an example of typical post-evaluation OBJSTAT output:
And the following is an example of typical post-evaluation OBJSTAT output:
<pre>
<p class="code">MSIR.0884: OBJECT LONG: objects/VTBL/STBL - 2/7/0, count/pages swapped 571/571
    MSIR.0884: OBJECT LONG: objects/VTBL/STBL - 2/7/0, count/pages
MSIR.0884: OBJECT PT: objects/VTBL/STBL - 2/18/0, count/pages swapped 310/310
                swapped 571/571
MSIR.0884: OBJECT CELL: objects/VTBL/STBL - 2/20/0, count/pages swapped 528/528
    MSIR.0884: OBJECT PT: objects/VTBL/STBL - 2/18/0, count/pages
MMSIR.0884: COLLECTION SYSTEM:ARRAYLIST OF OBJECT PT: objects/VTBL/STBL - 3/25/0, count/pages swapped 0/0
                swapped 310/310
MSIR.0884: OBJECT SYSTEM:STRINGLIST: objects/VTBL/STBL - 3/18/0, count/pages swapped 0/0
    MSIR.0884: OBJECT CELL: objects/VTBL/STBL - 2/20/0, count/pages
MSIR.0884: *TOTAL*: objects/VTBL/STBL - 14/163/144, count/pages swapped 1409/1409
                swapped 528/528
</p>
    MSIR.0884: OBJECT BOX: objects/VTBL/STBL - 2/75/144, count/pages
                swapped 0/0
    MSIR.0884: COLLECTION SYSTEM:ARRAYLIST OF OBJECT PT:
                objects/VTBL/STBL - 3/25/0, count/pages swapped 0/0
    MSIR.0884: OBJECT SYSTEM:STRINGLIST: objects/VTBL/STBL - 3/18/0,
                count/pages swapped 0/0
    MSIR.0884: *TOTAL*: objects/VTBL/STBL - 14/163/144, count/pages
                swapped 1409/1409
</pre>


As can be seen from this example, the object statistics can take up a fair
==Usage notes==
<ul>
<li>As can be seen from this example, the object statistics can take up a fair
amount of space and, in many cases, be quite uninteresting &mdash; classes
amount of space and, in many cases, be quite uninteresting &mdash; classes
without any swapping are typically of not much interest in post-evaluation
without any swapping are typically of not much interest in post-evaluation statistics.
statistics.
The <var>[[OBJSTMIN parameter|OBJSTMIN]]</var> parameter can be used
The [[OBJSTMIN parameter]] can be used
to limit the quantity of object statistics logged to the journal to those
to limit the quantity of object statistics logged to the journal to those
statistics that are actually of interest.
statistics that are actually of interest.


Regardless of the setting of OBJSTAT and OBJSTMIN, the since-last, user, and
Regardless of the setting of <var>OBJSTAT</var> and <var>OBJSTMIN</var>, the since-last, user, and
system OBJSWAP statistics are incremented for every object swap.
system <var>OBJSWAP</var> statistics are incremented for every object swap.
It is probably worth looking at these stats before deciding whether to try to
It is probably worth looking at these stats before deciding whether to try to
track down the cause of object swapping using OBJSTAT &mdash; if the OBJSWAP
track down the cause of object swapping using <var>OBJSTAT</var> &mdash; if the <var>OBJSWAP</var>
numbers are relatively low, it's probably not worth much effort looking at
numbers are relatively low, it's probably not worth much effort looking at
detailed object-swapping statistics.
detailed object-swapping statistics.


'''Note:'''
<li>For more information about object swapping, see [[Managing server space for objects#Swapping objects|Managing server space for objects]].
Before [[Sirius Mods]] version 6.9, OBJSTAT was a system manager resettable system parameter.
</ul>
 
For more information about object swapping, see the [[Janus SOAP Reference Manual]].


[[Category:User parameters]]
[[Category:User parameters]]
[[Category:Parameters]]
[[Category:Parameters]]

Latest revision as of 21:13, 17 October 2013

Sirius object statistic flags

Summary

Default value
X'00'
Parameter type
User
Where set
User and $Resetn resettable
Related products
Janus SOAP
Introduced
Sirius Mods 6.7

Description

This bitmask parameter controls the display of journal messages that contain user statistics about SOUL object usage per request. The messages specify server table usage (VTBL and STBL) and object-swapping counts per object class and summed for all classes.

The meanings of the bits in the OBJSTAT parameter are:

X'01'
Display post-compilation object statistics to the journal.
X'02'
Display post-evaluation object statistics to the journal.
X'10'
Display post-compilation object statistics to both the terminal and the journal. If this bit is on, it doesn't matter whether the X'01' bit is on or off — post-compilation statistics will still go to the journal.
X'20'
Display post-evaluation object statistics to both the terminal and the journal. If this bit is on, it doesn't matter whether the X'02' bit is on or off — post-evaluation statistics will still go to the journal.

The layout for the OBJSTAT messages is:

  • One message for each class of objects in the program, with this format:

    MSIR.0884: OBJECT classname: objects/VTBL/STBL - x/y/z, count/pages swapped a/b

  • A single message that reports the sum of the counts of the preceding individual classes, with this format:

    MSIR.0884: *TOTAL*: objects/VTBL/STBL - x/y/z, count/pages swapped a/b

Where:

classname Identifies the name of the class for which space for object instances is allocated.

Sirius system classes are prefixed with SYSTEM: or COLLECTION:, as applies. Sirius enumerations are excluded because they do not take up server space outside

of what is used for the enumeration variables themselves.
x The number of object instances for which server space is allocated for the

indicated class for the request. Note that this is different from the number of object variables in a request. Object variables also take up table space, but they are fixed in size (and relatively small) and number at compile time. The actual objects, on the other hand, can be quite large, and they can often have a very large number of instances created at evaluation time.

Unless a Sirius compiler directive is specified, this number reflects the number of objects that SOUL has determined is the minimum required. Server and, in some cases for system classes, space might be required for three or four objects.

y The VTBL units (32 bytes per unit) occupied by the allocated object instances.

Each instance of an object in a given class requires the same amount of space: a fixed amount for an object header, and a non-fixed amount for each member variable (that is, every variable in the Public or Private — but not Public Shared or Private Shared — blocks).

The VTBL units reported here do not include the VTBL space that is occupied by each local object reference in the main program routine. These references include object variables in declarations (including method parameter declarations and explicit and implicit method objects) and "work" object variables. These work variables are used to hold intermediate results in the evaluation of statements containing method concatenations. They may be reused within the class, and they typically do not add significantly to the VTBL space used. Object references use 2 VTBL units each, excepting XmlNode objects, which use approximately 8.

a The number of object swaps.

This is the number of times objects of this class were swapped into or out of the server during the request. A swap out counts as one, and a swap in as one, so a swap in and out counts as two. Accessing a global/session object counts as a swap in, since objects do not stay in the server between requests, so they need to be swapped into/out of CCATEMP.

Swaps happen only during evaluation, so this number should always be zero in the post-compilation statistics.

b The number of 6144-byte pages swapped into or out of the server. This number should always be an integral multiple of count, and the multiplier should be one, except for very large objects (greater than 6144 bytes).

The following is an example of typical post-compilation OBJSTAT output:

MSIR.0884: OBJECT LONG: objects/VTBL/STBL - 2/7/0, count/pages swapped 0/0 MSIR.0884: OBJECT PT: objects/VTBL/STBL - 2/18/0, count/pages swapped 0/0 MSIR.0884: OBJECT CELL: objects/VTBL/STBL - 2/20/0, count/pages swapped 0/0 MSIR.0884: OBJECT BOX: objects/VTBL/STBL - 2/75/144, count/pages swapped 0/0 MSIR.0884: COLLECTION SYSTEM:ARRAYLIST OF OBJECT PT: objects/VTBL/STBL - 3/25/0, count/pages swapped 0/0 MSIR.0884: OBJECT SYSTEM:STRINGLIST: objects/VTBL/STBL - 3/18/0, count/pages swapped 0/0 MSIR.0884: *TOTAL*: objects/VTBL/STBL - 14/163/144, count/pages swapped 0/0

And the following is an example of typical post-evaluation OBJSTAT output:

MSIR.0884: OBJECT LONG: objects/VTBL/STBL - 2/7/0, count/pages swapped 571/571 MSIR.0884: OBJECT PT: objects/VTBL/STBL - 2/18/0, count/pages swapped 310/310 MSIR.0884: OBJECT CELL: objects/VTBL/STBL - 2/20/0, count/pages swapped 528/528 MMSIR.0884: COLLECTION SYSTEM:ARRAYLIST OF OBJECT PT: objects/VTBL/STBL - 3/25/0, count/pages swapped 0/0 MSIR.0884: OBJECT SYSTEM:STRINGLIST: objects/VTBL/STBL - 3/18/0, count/pages swapped 0/0 MSIR.0884: *TOTAL*: objects/VTBL/STBL - 14/163/144, count/pages swapped 1409/1409

Usage notes

  • As can be seen from this example, the object statistics can take up a fair amount of space and, in many cases, be quite uninteresting — classes without any swapping are typically of not much interest in post-evaluation statistics. The OBJSTMIN parameter can be used to limit the quantity of object statistics logged to the journal to those statistics that are actually of interest. Regardless of the setting of OBJSTAT and OBJSTMIN, the since-last, user, and system OBJSWAP statistics are incremented for every object swap. It is probably worth looking at these stats before deciding whether to try to track down the cause of object swapping using OBJSTAT — if the OBJSWAP numbers are relatively low, it's probably not worth much effort looking at detailed object-swapping statistics.
  • For more information about object swapping, see Managing server space for objects.