Rechercher dans le manuel MySQL

26.12.2.3 The setup_instruments Table

The setup_instruments table lists classes of instrumented objects for which events can be collected:

  1. mysql> SELECT * FROM performance_schema.setup_instruments\G
  2. *************************** 1. row ***************************
  3. NAME: wait/synch/mutex/pfs/LOCK_pfs_share_list
  4. ENABLED: NO
  5. TIMED: NO
  6. PROPERTIES: singleton
  7. VOLATILITY: 1
  8. DOCUMENTATION: Components can provide their own performance_schema tables.
  9. This lock protects the list of such tables definitions.
  10. ...
  11. *************************** 369. row ***************************
  12. NAME: stage/sql/executing
  13. ENABLED: NO
  14. TIMED: NO
  15. PROPERTIES:
  16. VOLATILITY: 0
  17. DOCUMENTATION: NULL
  18. ...
  19. *************************** 687. row ***************************
  20. NAME: statement/abstract/Query
  21. ENABLED: YES
  22. TIMED: YES
  23. PROPERTIES: mutable
  24. VOLATILITY: 0
  25. DOCUMENTATION: SQL query just received from the network. At this point,
  26. the real statement type is unknown, the type will be
  27. refined after SQL parsing.
  28. ...
  29. *************************** 696. row ***************************
  30. NAME: memory/performance_schema/metadata_locks
  31. ENABLED: YES
  32. TIMED: NULL
  33. PROPERTIES: global_statistics
  34. VOLATILITY: 1
  35. DOCUMENTATION: Memory used for table performance_schema.metadata_locks
  36. ...

Each instrument added to the source code provides a row for the setup_instruments table, even when the instrumented code is not executed. When an instrument is enabled and executed, instrumented instances are created, which are visible in the xxx_instances tables, such as file_instances or rwlock_instances.

Modifications to most setup_instruments rows affect monitoring immediately. For some instruments, modifications are effective only at server startup; changing them at runtime has no effect. This affects primarily mutexes, conditions, and rwlocks in the server, although there may be other instruments for which this is true.

For more information about the role of the setup_instruments table in event filtering, see Section 26.4.3, “Event Pre-Filtering”.

The setup_instruments table has these columns:

  • NAME

    The instrument name. Instrument names may have multiple parts and form a hierarchy, as discussed in Section 26.6, “Performance Schema Instrument Naming Conventions”. Events produced from execution of an instrument have an EVENT_NAME value that is taken from the instrument NAME value. (Events do not really have a name, but this provides a way to associate events with instruments.)

  • ENABLED

    Whether the instrument is enabled. The value is YES or NO. A disabled instrument produces no events. This column can be modified, although setting ENABLED has no effect for instruments that have already been created.

  • TIMED

    Whether the instrument is timed. The value is YES, NO, or NULL. This column can be modified, although setting TIMED has no effect for instruments that have already been created.

    A TIMED value of NULL indicates that the instrument does not support timing. For example, memory operations are not timed, so their TIMED column is NULL.

    Setting TIMED to NULL for an instrument that supports timing has no effect, as does setting TIMED to non-NULL for an instrument that does not support timing.

    If an enabled instrument is not timed, the instrument code is enabled, but the timer is not. Events produced by the instrument have NULL for the TIMER_START, TIMER_END, and TIMER_WAIT timer values. This in turn causes those values to be ignored when calculating the sum, minimum, maximum, and average time values in summary tables.

  • PROPERTIES

    The instrument properties. This column uses the SET data type, so multiple flags from the following list can be set per instrument:

    • global_statistics: The instrument produces only global summaries. Summaries for finer levels are unavailable, such as per thread, account, user, or host. For example, most memory instruments produce only global summaries.

    • mutable: The instrument can mutate into a more specific one. This property applies only to statement instruments.

    • progress: The instrument is capable of reporting progress data. This property applies only to stage instruments.

    • singleton: The instrument has a single instance. For example, most global mutex locks in the server are singletons, so the corresponding instruments are as well.

    • user: The instrument is directly related to user workload (as opposed to system workload). One such instrument is wait/io/socket/sql/client_connection.

  • VOLATILITY

    The instrument volatility. Volatility values range from low to high. The values correspond to the PSI_VOLATILITY_xxx constants defined in the mysql/psi/psi_base.h header file:

    #define PSI_VOLATILITY_UNKNOWN 0
    #define PSI_VOLATILITY_PERMANENT 1
    #define PSI_VOLATILITY_PROVISIONING 2
    #define PSI_VOLATILITY_DDL 3
    #define PSI_VOLATILITY_CACHE 4
    #define PSI_VOLATILITY_SESSION 5
    #define PSI_VOLATILITY_TRANSACTION 6
    #define PSI_VOLATILITY_QUERY 7
    #define PSI_VOLATILITY_INTRA_QUERY 8

    The VOLATILITY column is purely informational, to provide users (and the Performance Schema code) some hint about the instrument runtime behavior.

    Instruments with a low volatility index (PERMANENT = 1) are created once at server startup, and never destroyed or re-created during normal server operation. They are destroyed only during server shutdown.

    For example, the wait/synch/mutex/pfs/LOCK_pfs_share_list mutex is defined with a volatility of 1, which means it is created once. Possible overhead from the instrumentation itself (namely, mutex initialization) has no effect for this instrument then. Runtime overhead occurs only when locking or unlocking the mutex.

    Instruments with a higher volatility index (for example, SESSION = 5) are created and destroyed for every user session. For example, the wait/synch/mutex/sql/THD::LOCK_query_plan mutex is created each time a session connects, and destroyed when the session disconnects.

    This mutex is more sensitive to Performance Schema overhead, because overhead comes not only from the lock and unlock instrumentation, but also from mutex create and destroy instrumentation, which is executed more often.

    Another aspect of volatility concerns whether and when an update to the ENABLED column actually has some effect:

    • An update to ENABLED affects instrumented objects created subsequently, but has no effect on instruments already created.

    • Instruments that are more volatile use new settings from the setup_instruments table sooner.

    For example, this statement does not affect the LOCK_query_plan mutex for existing sessions, but does have an effect on new sessions created subsequent to the update:

    1. UPDATE performance_schema.setup_instruments
    2. SET ENABLED=value
    3. WHERE NAME = 'wait/synch/mutex/sql/THD::LOCK_query_plan';

    This statement actually has no effect at all:

    1. UPDATE performance_schema.setup_instruments
    2. SET ENABLED=value
    3. WHERE NAME = 'wait/synch/mutex/pfs/LOCK_pfs_share_list';

    This mutex is permanent, and was created already before the update is executed. The mutex is never created again, so the ENABLED value in setup_instruments is never used. To enable or disable this mutex, use the mutex_instances table instead.

  • DOCUMENTATION

    A string describing the instrument purpose. The value is NULL if no description is available.

The setup_instruments table has these indexes:

  • Primary key on (NAME)

TRUNCATE TABLE is not permitted for the setup_instruments table.


Rechercher dans le manuel MySQL

Traduction non disponible

Le manuel MySQL n'est pas encore traduit en français sur l'infobrol. Seule la version anglaise est disponible pour l'instant.

Document créé le 26/06/2006, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/mysql-rf-performance-schema-setup-instruments-table.html

L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.

Références

  1. Consulter le document html Langue du document :en Manuel MySQL : https://dev.mysql.com/

Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.

Table des matières Haut