Documentation Home
MySQL 9.3 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.8Mb
PDF (A4) - 40.9Mb
Man Pages (TGZ) - 261.1Kb
Man Pages (Zip) - 368.3Kb
Info (Gzip) - 4.1Mb
Info (Zip) - 4.1Mb


29.12.2.3 The setup_instruments Table

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

mysql> SELECT * FROM performance_schema.setup_instruments\G*************************** 1. row ***************************         NAME: wait/synch/mutex/pfs/LOCK_pfs_share_list      ENABLED: NO        TIMED: NO   PROPERTIES: singleton        FLAGS: NULL   VOLATILITY: 1DOCUMENTATION: Components can provide their own performance_schema tables. This lock protects the list of such tables definitions....*************************** 410. row ***************************         NAME: stage/sql/executing      ENABLED: NO        TIMED: NO   PROPERTIES:        FLAGS: NULL   VOLATILITY: 0DOCUMENTATION: NULL...*************************** 733. row ***************************         NAME: statement/abstract/Query      ENABLED: YES        TIMED: YES   PROPERTIES: mutable        FLAGS: NULL   VOLATILITY: 0DOCUMENTATION: SQL query just received from the network. At this point, the real statement type is unknown, the type will be refined after SQL parsing....*************************** 737. row ***************************         NAME: memory/performance_schema/mutex_instances      ENABLED: YES        TIMED: NULL   PROPERTIES: global_statistics        FLAGS:   VOLATILITY: 1DOCUMENTATION: Memory used for table performance_schema.mutex_instances...*************************** 823. row ***************************         NAME: memory/sql/Prepared_statement::infrastructure      ENABLED: YES        TIMED: NULL   PROPERTIES: controlled_by_default        FLAGS: controlled   VOLATILITY: 0DOCUMENTATION: Map infrastructure for prepared statements per session....

Each instrument added to the source code provides a row for thesetup_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 thexxx_instances tables, such asfile_instances orrwlock_instances.

Modifications to mostsetup_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 thesetup_instruments table in event filtering, seeSection 29.4.3, “Event Pre-Filtering”.

Thesetup_instruments table has these columns:

  • NAME

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

  • ENABLED

    Whether the instrument is enabled. The value isYES orNO. A disabled instrument produces no events. This column can be modified, although settingENABLED has no effect for instruments that have already been created.

  • TIMED

    Whether the instrument is timed. The value isYES,NO, orNULL. This column can be modified, although settingTIMED has no effect for instruments that have already been created.

    ATIMED value ofNULL indicates that the instrument does not support timing. For example, memory operations are not timed, so theirTIMED column isNULL.

    SettingTIMED toNULL for an instrument that supports timing has no effect, as does settingTIMED 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 haveNULL for theTIMER_START,TIMER_END, andTIMER_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 theSET data type, so multiple flags from the following list can be set per instrument:

    • controlled_by_default: memory is collected by default for this 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 canmutate 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 iswait/io/socket/sql/client_connection.

  • FLAGS

    Whether the instrument's memory is controlled.

    This flag is supported for non-global memory instruments, only, and can be set or unset. For example:

                  SQL> UPDATE PERFORMANCE_SCHEMA.SETUP_INTRUMENTS SET FLAGS="controlled" WHERE NAME='memory/sql/NET::buff';
    Note

    Attempting to setFLAGS = controlled on non-memory instruments, or on global memory instruments, fails silently.

  • VOLATILITY

    The instrument volatility. Volatility values range from low to high. The values correspond to thePSI_VOLATILITY_xxx constants defined in themysql/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

    TheVOLATILITY 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, thewait/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, thewait/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 theENABLED column actually has some effect:

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

    • Instruments that are morevolatile use new settings from thesetup_instruments table sooner.

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

    UPDATE performance_schema.setup_instrumentsSET ENABLED=valueWHERE NAME = 'wait/synch/mutex/sql/THD::LOCK_query_plan';

    This statement actually has no effect at all:

    UPDATE performance_schema.setup_instrumentsSET ENABLED=valueWHERE 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 theENABLED value insetup_instruments is never used. To enable or disable this mutex, use themutex_instances table instead.

  • DOCUMENTATION

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

Thesetup_instruments table has these indexes:

  • Primary key on (NAME)

TRUNCATE TABLE is not permitted for thesetup_instruments table.

To assist monitoring and troubleshooting, the Performance Schema instrumentation is used to export names of instrumented threads to the operating system. This enables utilities that display thread names, such as debuggers and the Unixps command, to display distinctmysqld thread names rather thanmysqld. This feature is supported only on Linux, macOS, and Windows.

Suppose thatmysqld is running on a system that has a version ofps that supports this invocation syntax:

ps -C mysqld H -o "pid tid cmd comm"

Without export of thread names to the operating system, the command displays output like this, where mostCOMMAND values aremysqld:

  PID   TID CMD                         COMMAND 1377  1377 /usr/sbin/mysqld            mysqld 1377  1528 /usr/sbin/mysqld            mysqld 1377  1529 /usr/sbin/mysqld            mysqld 1377  1530 /usr/sbin/mysqld            mysqld 1377  1531 /usr/sbin/mysqld            mysqld 1377  1534 /usr/sbin/mysqld            mysqld 1377  1535 /usr/sbin/mysqld            mysqld 1377  1588 /usr/sbin/mysqld            xpl_worker1 1377  1589 /usr/sbin/mysqld            xpl_worker0 1377  1590 /usr/sbin/mysqld            mysqld 1377  1594 /usr/sbin/mysqld            mysqld 1377  1595 /usr/sbin/mysqld            mysqld

With export of thread names to the operating system, the output looks like this, with threads having a name similar to their instrument name:

  PID   TID CMD                         COMMAND27668 27668 /usr/sbin/mysqld            mysqld27668 27671 /usr/sbin/mysqld            ib_io_ibuf27668 27672 /usr/sbin/mysqld            ib_io_log27668 27673 /usr/sbin/mysqld            ib_io_rd-127668 27674 /usr/sbin/mysqld            ib_io_rd-227668 27677 /usr/sbin/mysqld            ib_io_wr-127668 27678 /usr/sbin/mysqld            ib_io_wr-227668 27699 /usr/sbin/mysqld            xpl_worker-227668 27700 /usr/sbin/mysqld            xpl_accept-127668 27710 /usr/sbin/mysqld            evt_sched27668 27711 /usr/sbin/mysqld            sig_handler27668 27933 /usr/sbin/mysqld            connection

Different thread instances within the same class are numbered to provide distinct names where that is feasible. Due to constraints on name lengths with respect to potentially large numbers of connections, connections are named simplyconnection.