Author: pd221994
Date: 2011-03-19 17:11:58 +0100 (Sat, 19 Mar 2011)
New Revision: 25450
Log:
r46064@dhcp-adc-twvpn-1-vpnpool-10-154-9-163: paul | 2011-03-19 11:09:08 -0500
P_S general revisions
Modified:
svk:merge
trunk/refman-5.5/performance-schema-core.xml
trunk/refman-5.6/performance-schema-core.xml
trunk/refman-6.0/performance-schema-core.xml
Property changes on: trunk
___________________________________________________________________
Modified: svk:merge
===================================================================
Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 1277 bytes
Modified: trunk/refman-5.5/performance-schema-core.xml
===================================================================
--- trunk/refman-5.5/performance-schema-core.xml 2011-03-19 16:11:53 UTC (rev 25449)
+++ trunk/refman-5.5/performance-schema-core.xml 2011-03-19 16:11:58 UTC (rev 25450)
Changed blocks: 5, Lines Added: 28, Lines Deleted: 26; 4366 bytes
@@ -1128,7 +1128,7 @@
<section id="performance-schema-filtering">
- <title>Event Collection Filtering</title>
+ <title>Event Filtering</title>
<indexterm>
<primary>Performance Schema</primary>
@@ -1189,7 +1189,7 @@
Performance Schema tables are the destinations for events and
consume events. The
<literal role="ps">setup_consumers</literal> table lists the
- types of consumers for which event information can be stored:
+ types of consumers to which event information can be sent:
</para>
<programlisting>
@@ -1220,12 +1220,12 @@
<listitem>
<para>
- Pre-filtering is done by modifying Performance Schema
- configuration so that only certain types of events are
- collected from producers, and collected events are used to
- update only certain consumers. This type of filtering is done
- by Performance Schema and has a global effect that applies to
- all users.
+ <emphasis role="bold">Pre-filtering.</emphasis> This is done
+ by modifying Performance Schema configuration so that only
+ certain types of events are collected from producers, and
+ collected events are used to update only certain consumers.
+ This type of filtering is done by Performance Schema and has a
+ global effect that applies to all users.
</para>
<para>
@@ -1272,12 +1272,12 @@
<listitem>
<para>
- Post-filtering involves the use of <literal>WHERE</literal>
- clauses when selecting information from Performance Schema
- tables, to specify which of the available events you want to
- see. This type of filtering is performed on a per-user basis
- because individual users select which of the available events
- are of interest.
+ <emphasis role="bold">Post-filtering.</emphasis> This involves
+ the use of <literal>WHERE</literal> clauses when selecting
+ information from Performance Schema tables, to specify which
+ of the available events you want to see. This type of
+ filtering is performed on a per-user basis because individual
+ users select which of the available events are of interest.
</para>
<para>
@@ -1467,21 +1467,23 @@
</para>
<para>
- Changing which instruments are enabled or timed does not flush
- the history tables. Events already collected remain in the
- current-events and history tables until displaced by newer
- events. If you disable instruments, you might need to wait a
- while before events for them are displaced by newer events of
- interest. Alternatively, use <literal role="stmt">TRUNCATE
- TABLE</literal> to empty the history tables.
+ When you change which instruments are enabled or timed,
+ Performance Schema does not flush the history tables. Events
+ already collected remain in the current-events and history
+ tables until displaced by newer events. If you disable
+ instruments, you might need to wait a while before events for
+ them are displaced by newer events of interest. Alternatively,
+ use <literal role="stmt">TRUNCATE TABLE</literal> to empty the
+ history tables.
</para>
<para>
- You might want to truncate the summary tables as well to clear
- aggregate information for previously collected events. With
- summary tables, the effect of <literal role="stmt">TRUNCATE
- TABLE</literal> is to reset the summary columns to 0 or
- <literal>NULL</literal>, not to remove rows.
+ After instrumentation changes, you might want to truncate the
+ summary tables as well to clear aggregate information for
+ previously collected events. With summary tables, the effect of
+ <literal role="stmt">TRUNCATE TABLE</literal> is to reset the
+ summary columns to 0 or <literal>NULL</literal>, not to remove
+ rows.
</para>
<para>
Modified: trunk/refman-5.6/performance-schema-core.xml
===================================================================
--- trunk/refman-5.6/performance-schema-core.xml 2011-03-19 16:11:53 UTC (rev 25449)
+++ trunk/refman-5.6/performance-schema-core.xml 2011-03-19 16:11:58 UTC (rev 25450)
Changed blocks: 19, Lines Added: 241, Lines Deleted: 92; 20402 bytes
@@ -1123,7 +1123,7 @@
<section id="performance-schema-filtering">
- <title>Event Collection Filtering</title>
+ <title>Event Filtering</title>
<indexterm>
<primary>Performance Schema</primary>
@@ -1192,7 +1192,7 @@
Performance Schema tables are the destinations for events and
consume events. The
<literal role="ps">setup_consumers</literal> table lists the
- types of consumers for which event information can be stored:
+ types of consumers to which event information can be sent:
</para>
<programlisting>
@@ -1220,12 +1220,12 @@
<listitem>
<para>
- Pre-filtering is done by modifying Performance Schema
- configuration so that only certain types of events are
- collected from producers, and collected events are used to
- update only certain consumers. This type of filtering is done
- by Performance Schema and has a global effect that applies to
- all users.
+ <emphasis role="bold">Pre-filtering.</emphasis> This is done
+ by modifying Performance Schema configuration so that only
+ certain types of events are collected from producers, and
+ collected events are used to update only certain consumers.
+ This type of filtering is done by Performance Schema and has a
+ global effect that applies to all users.
</para>
<para>
@@ -1272,12 +1272,12 @@
<listitem>
<para>
- Post-filtering involves the use of <literal>WHERE</literal>
- clauses when selecting information from Performance Schema
- tables, to specify which of the available events you want to
- see. This type of filtering is performed on a per-user basis
- because individual users select which of the available events
- are of interest.
+ <emphasis role="bold">Post-filtering.</emphasis> This involves
+ the use of <literal>WHERE</literal> clauses when selecting
+ information from Performance Schema tables, to specify which
+ of the available events you want to see. This type of
+ filtering is performed on a per-user basis because individual
+ users select which of the available events are of interest.
</para>
<para>
@@ -1362,10 +1362,6 @@
<para>
The <literal role="ps">threads</literal> table indicates
whether monitoring is enabled for each server thread.
- (This has no effect unless the
- <literal>thread_instrumentation</literal> consumer in
- <literal role="ps">setup_consumers</literal> table is
- enabled.)
</para>
</listitem>
@@ -1389,15 +1385,35 @@
<para>
The <literal role="ps">setup_consumers</literal> table also
- has an effect on event production. If a given event will not
- be sent to any destination (that is, will not be consumed),
- Performance Schema does not bother to produce it.
+ implicitly affects event production. If a given event will
+ not be sent to any destination (that is, will not be
+ consumed), Performance Schema does not produce it.
</para>
</listitem>
</itemizedlist>
<para>
+ When you change which instruments are enabled or timed,
+ Performance Schema does not flush the history tables. Events
+ already collected remain in the current-events and history
+ tables until displaced by newer events. If you disable
+ instruments, you might need to wait a while before events for
+ them are displaced by newer events of interest. Alternatively,
+ use <literal role="stmt">TRUNCATE TABLE</literal> to empty the
+ history tables.
+ </para>
+
+ <para>
+ After instrumentation changes, you might want to truncate the
+ summary tables as well to clear aggregate information for
+ previously collected events. With summary tables, the effect of
+ <literal role="stmt">TRUNCATE TABLE</literal> is to reset the
+ summary columns to 0 or <literal>NULL</literal>, not to remove
+ rows.
+ </para>
+
+ <para>
The following sections describe how to use the tables that
control how Performance Schema performs pre-filtering.
</para>
@@ -1408,12 +1424,39 @@
<para>
The <literal role="ps">setup_instruments</literal> table lists
- the available instruments. To control whether an instrument is
- enabled, set its <literal>ENABLED</literal> column to
- <literal>YES</literal> or <literal>NO</literal>. To configure
- whether to collect timing information for an instrument, set
- its <literal>TIMED</literal> value to <literal>YES</literal>
- or <literal>NO</literal>. Setting the <literal>TIMED</literal>
+ the available instruments:
+ </para>
+
+<programlisting>
+mysql> <userinput>SELECT * FROM setup_instruments;</userinput>
++------------------------------------------------------------+---------+-------+
+| NAME | ENABLED | TIMED |
++------------------------------------------------------------+---------+-------+
+...
+| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
+| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
+| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
+| wait/synch/mutex/sql/LOCK_manager | YES | YES |
+...
+| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
+| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
+| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
+| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
+...
+| wait/io/file/sql/binlog | YES | YES |
+| wait/io/file/sql/binlog_index | YES | YES |
+| wait/io/file/sql/casetest | YES | YES |
+| wait/io/file/sql/dbopt | YES | YES |
+...
+</programlisting>
+
+ <para>
+ To control whether an instrument is enabled, set its
+ <literal>ENABLED</literal> column to <literal>YES</literal> or
+ <literal>NO</literal>. To configure whether to collect timing
+ information for an instrument, set its
+ <literal>TIMED</literal> value to <literal>YES</literal> or
+ <literal>NO</literal>. Setting the <literal>TIMED</literal>
column to <literal>NO</literal> affects Performance Schema
table contents as described in
<xref linkend="performance-schema-timing"/>.
@@ -1526,23 +1569,11 @@
</itemizedlist>
<para>
- Changing which instruments are enabled or timed does not flush
- the history tables. Events already collected remain in the
- current-events and history tables until displaced by newer
- events. If you disable instruments, you might need to wait a
- while before events for them are displaced by newer events of
- interest. Alternatively, use <literal role="stmt">TRUNCATE
- TABLE</literal> to empty the history tables.
+ Modifications to the
+ <literal role="ps">setup_instruments</literal> table affect
+ monitoring immediately.
</para>
- <para>
- You might want to truncate the summary tables as well to clear
- aggregate information for previously collected events. With
- summary tables, the effect of <literal role="stmt">TRUNCATE
- TABLE</literal> is to reset the summary columns to 0 or
- <literal>NULL</literal>, not to remove rows.
- </para>
-
</section>
<section id="performance-schema-object-filtering">
@@ -1567,24 +1598,109 @@
</programlisting>
<para>
+ The <literal>OBJECT_SCHEMA</literal> and
+ <literal>OBJECT_NAME</literal> columns should name a specific
+ schema or table, or <literal>'%'</literal> to match any name.
+ Performance Schema tries to find more specific matches first,
+ <literal>'%'</literal> matches last.
+ </para>
+
+ <para>
For table-related events, the contents of
<literal role="ps">setup_objects</literal> are combined with
- <literal role="ps">setup_instruments</literal>. That is,
- enabled table instruments produce events only for those tables
- that match the <literal>OBJECT_SCHEMA</literal> and
- <literal>OBJECT_NAME</literal> columns of some row in
- <literal role="ps">setup_objects</literal>.
+ <literal role="ps">setup_instruments</literal>:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Enabled table instruments produce events only for those
+ tables that match the <literal>OBJECT_SCHEMA</literal> and
+ <literal>OBJECT_NAME</literal> columns of some row in
+ <literal role="ps">setup_objects</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>TIMED</literal> values in the two tables are
+ combined, so that timing information is collected only
+ with both values are <literal>YES</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<para>
- A value of <literal>'%'</literal> in the
- <literal>OBJECT_SCHEMA</literal> or
- <literal>OBJECT_NAME</literal> column means <quote>match any
- name,</quote> so by default, monitoring is enabled for all
- tables.
+ Because the <literal role="ps">setup_objects</literal> table
+ initially contains a row with <literal>'%'</literal> for both
+ <literal>OBJECT_SCHEMA</literal> and
+ <literal>OBJECT_NAME</literal>, by default, monitoring is
+ enabled for all tables.
</para>
<para>
+ Suppose that <literal role="ps">setup_objects</literal>
+ contains the following rows:
+ </para>
+
+<programlisting>
++-------------+---------------+-------------+-------+
+| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | TIMED |
++-------------+---------------+-------------+-------+
+| TABLE | db1 | t1 | YES |
+| TABLE | db1 | t2 | NO |
+| TABLE | db2 | % | YES |
+| TABLE | db3 | % | NO |
+| TABLE | % | % | YES |
++-------------+---------------+-------------+-------+
+</programlisting>
+
+ <para>
+ If a table-related instrument in
+ <literal role="ps">setup_instruments</literal> has a
+ <literal>TIMED</literal> value of <literal>NO</literal>, no
+ events for the instrument are timed. If the
+ <literal>TIMED</literal> value is <literal>YES</literal>,
+ events timing occurs as follows:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>db1.t1</literal> is timed
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>db1.t2</literal> is not timed
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>db2.t3</literal> is timed
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>db3.t4</literal> is not timed
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>db4.t5</literal> is timed
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
If a persistent table and a temporary table have the same
name, matching against
<literal role="ps">setup_objects</literal> rows occurs the
@@ -1594,10 +1710,9 @@
</para>
<para>
- Setting the <literal>TIMED</literal> column for objects to
- <literal>NO</literal> affects Performance Schema table
- contents as described in
- <xref linkend="performance-schema-timing"/>.
+ Modifications to the
+ <literal role="ps">setup_objects</literal> table affect object
+ monitoring immediately.
</para>
</section>
@@ -1629,8 +1744,8 @@
<listitem>
<para>
- Monitoring occurs only for those events produced from
- instruments that are enabled, as specified in the
+ Monitoring occurs only for those thread events produced
+ from instruments that are enabled, as specified in the
<literal role="ps">setup_instruments</literal> table.
</para>
</listitem>
@@ -1668,12 +1783,23 @@
</programlisting>
<para>
+ Performance Schema uses the <literal>HOST</literal> and
+ <literal>USER</literal> columns to match each new foreground
+ thread. The <literal>INSTRUMENTED</literal> value becomes
+ <literal>YES</literal> if any row matches.
+ </para>
+
+ <para>
A value of <literal>'%'</literal> in the
<literal>HOST</literal> or <literal>USER</literal> column
- means <quote>match any name,</quote> so by default, monitoring
- is enabled for all new foreground threads. If you want to
- perform more limited matching, you must delete this row
- because it matches any connection.
+ means <quote>match any name.</quote> Because the
+ <literal role="ps">setup_actors</literal> table initially
+ contains a row with <literal>'%'</literal> for both
+ <literal>HOST</literal> and <literal>USER</literal>, by
+ default, monitoring is enabled for all new foreground threads.
+ If you want to perform more limited matching such as to enable
+ monitoring only for some foreground threads, you must delete
+ this row because it matches any connection.
</para>
<para>
@@ -1683,48 +1809,54 @@
<programlisting>
DELETE FROM setup_actors;
-INSERT INTO setup_actors VALUES('joe','localhost','%');
-INSERT INTO setup_actors VALUES('sam','%','%');
-INSERT INTO setup_actors VALUES('bill','%.example.net','%');
</programlisting>
<para>
- After the <literal role="stmt">DELETE</literal> statement,
- <literal>setup_actors</literal> sis empty, there are no rows
- that could match incoming connections, and any the
+ Now <literal>setup_actors</literal> is empty, there are no
+ rows that could match incoming connections, and any the
<literal>INSTRUMENTED</literal> column for new foreground
threads will be set to <literal>NO</literal>.
</para>
<para>
- After the <literal role="stmt">INSERT</literal> statements,
- connections match as follows:
+ Suppose that you further modify
+ <literal role="ps">setup_actors</literal>:
</para>
+<programlisting>
+INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('localhost','joe','%');
+INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('%','sam','%');
+</programlisting>
+
+ <para>
+ Now connections match as follows:
+ </para>
+
<itemizedlist>
<listitem>
<para>
If <literal>joe</literal> connects from the local host,
- there is a match to the first inserted row. If
- <literal>joe</literal> connects from any other host, there
- is no match.
+ there is a match to the first inserted row.
</para>
</listitem>
<listitem>
<para>
- If <literal>sam</literal> connects from any host, there is
- a match to the second inserted row.
+ If <literal>joe</literal> connects from any other host,
+ there is no match.
</para>
</listitem>
<listitem>
<para>
- If <literal>bill</literal> connects from any host in the
- <literal>example.net</literal> domain, there is a match to
- the third inserted row.
+ If <literal>sam</literal> connects from any host, there is
+ a match to the second inserted row.
</para>
+
+ <para>
+ For any other connection, there is no match.
+ </para>
</listitem>
</itemizedlist>
@@ -1741,6 +1873,24 @@
<title>Pre-Filtering by Consumer</title>
<para>
+ The <literal>setup_consumers</literal> table lists the
+ available consumer types:
+ </para>
+
+<programlisting>
+mysql> <userinput>SELECT * FROM setup_consumers;</userinput>
++---------------------------+---------+
+| NAME | ENABLED |
++---------------------------+---------+
+| events_waits_current | YES |
+| events_waits_history | YES |
+| events_waits_history_long | YES |
+| global_instrumentation | YES |
+| thread_instrumentation | YES |
++---------------------------+---------+
+</programlisting>
+
+ <para>
Modify the <literal role="ps">setup_consumers</literal> table
to affect pre-filtering at the consumer stage and determine
which destinations events are sent to. To enable or disable a
@@ -4139,9 +4289,8 @@
</para>
<para>
- The host name. Permissible values are as in the host name
- part of account names. See
- <xref linkend="account-names"/>.
+ The host name. The value <literal>'%'</literal> means
+ <quote>any host.</quote>
</para>
</listitem>
@@ -4151,10 +4300,8 @@
</para>
<para>
- The user name. Permissible values are as in the user name
- part of account names, except that <quote>any user</quote>
- is represented by <literal>'%'</literal> rather than the
- empty string. See <xref linkend="account-names"/>.
+ The user name. The value <literal>'%'</literal> means
+ <quote>any user.</quote>
</para>
</listitem>
@@ -6526,15 +6673,15 @@
<programlisting>
mysql> <userinput>SELECT * FROM threads\G</userinput>
*************************** 1. row ***************************
- THREAD_ID: 11
- NAME: thread/innodb/io_handler_thread
+ THREAD_ID: 1
+ NAME: thread/sql/main
TYPE: BACKGROUND
PROCESSLIST_ID: NULL
PROCESSLIST_USER: NULL
PROCESSLIST_HOST: NULL
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: NULL
- PROCESSLIST_TIME: NULL
+ PROCESSLIST_TIME: 80284
PROCESSLIST_STATE: NULL
PROCESSLIST_INFO: NULL
PARENT_THREAD_ID: NULL
@@ -6801,8 +6948,9 @@
<para>
For any thread, its <literal>INSTRUMENTED</literal>
value can be changed during the lifetime of the
- thread. This is the only table column that can be
- modified.
+ thread. This is the only
+ <literal role="ps">threads</literal> table column that
+ can be modified.
</para>
</listitem>
@@ -6831,8 +6979,9 @@
<listitem>
<para>
- Monitoring occurs only for those events produced from
- instruments that are enabled, as specified in the
+ Monitoring occurs only for those thread events
+ produced from instruments that are enabled, as
+ specified in the
<literal role="ps">setup_instruments</literal> table.
</para>
</listitem>
Modified: trunk/refman-6.0/performance-schema-core.xml
===================================================================
--- trunk/refman-6.0/performance-schema-core.xml 2011-03-19 16:11:53 UTC (rev 25449)
+++ trunk/refman-6.0/performance-schema-core.xml 2011-03-19 16:11:58 UTC (rev 25450)
Changed blocks: 5, Lines Added: 28, Lines Deleted: 26; 4366 bytes
@@ -1151,7 +1151,7 @@
<section id="performance-schema-filtering">
- <title>Event Collection Filtering</title>
+ <title>Event Filtering</title>
<indexterm>
<primary>Performance Schema</primary>
@@ -1212,7 +1212,7 @@
Performance Schema tables are the destinations for events and
consume events. The
<literal role="ps">setup_consumers</literal> table lists the
- types of consumers for which event information can be stored:
+ types of consumers to which event information can be sent:
</para>
<programlisting>
@@ -1243,12 +1243,12 @@
<listitem>
<para>
- Pre-filtering is done by modifying Performance Schema
- configuration so that only certain types of events are
- collected from producers, and collected events are used to
- update only certain consumers. This type of filtering is done
- by Performance Schema and has a global effect that applies to
- all users.
+ <emphasis role="bold">Pre-filtering.</emphasis> This is done
+ by modifying Performance Schema configuration so that only
+ certain types of events are collected from producers, and
+ collected events are used to update only certain consumers.
+ This type of filtering is done by Performance Schema and has a
+ global effect that applies to all users.
</para>
<para>
@@ -1295,12 +1295,12 @@
<listitem>
<para>
- Post-filtering involves the use of <literal>WHERE</literal>
- clauses when selecting information from Performance Schema
- tables, to specify which of the available events you want to
- see. This type of filtering is performed on a per-user basis
- because individual users select which of the available events
- are of interest.
+ <emphasis role="bold">Post-filtering.</emphasis> This involves
+ the use of <literal>WHERE</literal> clauses when selecting
+ information from Performance Schema tables, to specify which
+ of the available events you want to see. This type of
+ filtering is performed on a per-user basis because individual
+ users select which of the available events are of interest.
</para>
<para>
@@ -1490,21 +1490,23 @@
</para>
<para>
- Changing which instruments are enabled or timed does not flush
- the history tables. Events already collected remain in the
- current-events and history tables until displaced by newer
- events. If you disable instruments, you might need to wait a
- while before events for them are displaced by newer events of
- interest. Alternatively, use <literal role="stmt">TRUNCATE
- TABLE</literal> to empty the history tables.
+ When you change which instruments are enabled or timed,
+ Performance Schema does not flush the history tables. Events
+ already collected remain in the current-events and history
+ tables until displaced by newer events. If you disable
+ instruments, you might need to wait a while before events for
+ them are displaced by newer events of interest. Alternatively,
+ use <literal role="stmt">TRUNCATE TABLE</literal> to empty the
+ history tables.
</para>
<para>
- You might want to truncate the summary tables as well to clear
- aggregate information for previously collected events. With
- summary tables, the effect of <literal role="stmt">TRUNCATE
- TABLE</literal> is to reset the summary columns to 0 or
- <literal>NULL</literal>, not to remove rows.
+ After instrumentation changes, you might want to truncate the
+ summary tables as well to clear aggregate information for
+ previously collected events. With summary tables, the effect of
+ <literal role="stmt">TRUNCATE TABLE</literal> is to reset the
+ summary columns to 0 or <literal>NULL</literal>, not to remove
+ rows.
</para>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@oter02: r25450 - in trunk: . refman-5.5 refman-5.6 refman-6.0 | paul.dubois | 19 Mar |
