WL#7804: REPORT FOR SUPPORT
Affects: Server-5.7
—
Status: Complete
The aim is to implement a procedure in the sys schema that will allow the DBA to easily collect diagnostics data from a MySQL instance to investigate. The implementation will consist of: * sys.metrics - A view that includes the following data: - performance_schema.global_status - information_schema.INNODB_METRICS - Current memory allocation (as per the Performance Schema memory instruments) - Total memory allocated (as per the Performance Schema memory instruments) - The current time (in human readable format and as unix timestamp) The view should remove duplicate variables between the global status and the InnoDB metrics. The view should add columns to show where the variable comes from and whether it is enabled. For the Performance Schema memory instruments, these can be partially enabled. * sys.statement_performance_analyzer(...) - A procedure that can be used to use snapshots of performance_schema.events_statements_summary_by_digest together with the sys views based on performance_schema.events_statements_summary_by_digest to generate the view based on a single snapshot or the difference between two snapshots. * sys.diagnostics(...) - The main procedure which collects: * A configuration overview * Perform an iteration every N seconds for a total of maximum M seconds collecting: - sys.metrics view (or equivalent if performance_schema = OFF) - Relevant sys schema views - Replication status - Relevant ndbinfo tables (if mysqld is part of Cluster) * At the end overall (since server restart) statistics and the delta for each iteration for the sys.metrics view * The delta from the start of the execution to the end should be generated for several sys schema views including queries in the 95th percentile * For each iteration the output of: - SHOW ENGINE INNODB STATUS - information_schema.INNODB_TRX - sys.processlist - Memory information from the Performance Schema (using sys views) * Schema information * The output of SHOW ENGINE PERFORMANCE_SCHEMA STATUS. The procedure is able to perform a number of iterations based on the arguments provided, and it will be able to adjust the settings for the Performance Schema consumers and instruments. Given that the view / procedures are part of the product, customers do not need to be trained again and again to execute a different script/instructions, as the content of the procedure can change instead.
Function requirements: F-1: The sys.metrics view F-2: The sys.statement_performance_analyzer(...) stored procedure F-3: Provide the sys.diagnostics(...) stored procedure F-4: Add a row with each of the following options to the sys.sys_config table: * @sys.statement_performance_analyzer.limit ( variable = statement_performance_analyzer.limit, value = 100 ) * @sys.statement_performance_analyzer.view ( variable = sys.statement_performance_analyzer.view, value = NULL) * @diagnostics.allow_i_s_tables ( variable = diagnostics.allow_i_s_tables, value = OFF ) * @diagnostics.include_raw ( variable = diagnostics.include_raw, vaule = OFF ) Non-Functional requirements: NF-1: The impact on the rest of the system should be minimal (beyond what is expected from using the Performance Schema and other features in general). NF-2: No events should be logged to the binary log (accomplished through SET SESSION sql_log_bin = 0, so requires SUPER to execute the procedures)
sys.metrics ----------- The view will have the following columns: * Variable_name: The name of the variable, e.g. VARIABLE_NAME from performance_schema.global_status or the NAME column from information_schema.INNODB_METRICS. All variable names are in lower case. * Variable_value: The value, e.g. VARIABLE_VALUE from performance_schema.global_status or the COUNT column from information_schema.INNODB_METRICS. * Type: The variable type: one of Global Status, Performance Schema, System Time, or InnoDB Metrics concatenated with the value of the SUBSYSTEM column in information_schema.INNODB_METRICS. * Enabled: Whether the metrics is enabled. For global_status and system time this is always YES, for INNODB_METRICS it depends on the value of STATUS, for Performance Schema it can be YES, NO, or PARTIAL depending on whether the memory instruments are enabled. The following InnoDB metrics are explicitly filtered out as they have duplicate variables in global_status: 'lock_row_lock_time', 'lock_row_lock_time_avg', 'lock_row_lock_time_max', 'lock_row_lock_waits', 'buffer_pool_reads', 'buffer_pool_read_requests', 'buffer_pool_write_requests', 'buffer_pool_wait_free', 'buffer_pool_read_ahead', 'buffer_pool_read_ahead_evicted', 'buffer_pool_pages_total', 'buffer_pool_pages_misc', 'buffer_pool_pages_data', 'buffer_pool_bytes_data', 'buffer_pool_pages_dirty', 'buffer_pool_bytes_dirty', 'buffer_pool_pages_free', 'buffer_pages_created', 'buffer_pages_written', 'buffer_pages_read', 'buffer_data_reads', 'buffer_data_written', 'file_num_open_files', 'os_log_bytes_written', 'os_log_fsyncs', 'os_log_pending_fsyncs', 'os_log_pending_writes', 'log_waits', 'log_write_requests', 'log_writes', 'innodb_dblwr_writes', 'innodb_dblwr_pages_written', 'innodb_page_size' sys.statement_performance_analyzer(...) --------------------------------------- The procedure will take three arguments: * The action to complete. Supported actions are: - snapshot Store a snapshot. The default is to make a snapshot of the current content of performance_schema.events_statements_summary_by_digest, but by setting in_table this can be overwritten to copy the content of the specified table. The snapshot is stored in the sys.tmp_digests temporary table. - overall Generate analysis based on the content specified by in_table. For the overall analysis, the table argument (see below) can be NOW() to use a fresh snapshot. This will overwrite an existing snapshot. Use NULL for the table argument to use the existing snapshot. If in_table IS NULL and no snapshot exists, a new will be created. See also the view argument and @sys.statement_performance_analyzer.limit. - delta Generate a delta analysis. The delta will be calculated between the reference table in the table argument and the snapshot. An existing snapshot must exist. The action uses the sys.tmp_digests_delta temporary table. See also the view argument and @sys.statement_performance_analyzer.limit. - create_table Create a regular table suitable for storing the snapshot for later use, e.g. for calculating deltas. - create_tmp Create a temporary table suitable for storing the snapshot for later use, e.g. for calculating deltas. - save Save the snapshot in the table specified by the table arguement. The table must exists and have the correct structure. If no snapshot exists, a new is created. - cleanup Remove the temporary tables used for the snapshot and delta. * The table argument used for some actions. Use the format 'db1.t1' or 't1' without using any backticks (`) for quoting. Periods (.) are not supported in the database and table names. The meaning of the table for each action supporting the argument is: - snapshot The snapshot is created based on the specified table. Set to NULL or NOW() to use the current content of performance_schema.events_statements_summary_by_digest. - overall The table with the content to create the overall analyzis for. The following values can be used: o A table name - use the content of that table. o NOW() - create a fresh snapshot and overwrite the existing snapshot. o NULL - use the last stored snapshot. - delta The table name is mandatory and specified the reference view to compare the currently stored snapshot against. If no snapshot exists, a new will be created. - create_table The name of the regular table to create. - create_tmp The name of the temporary table to create. - save The name of the table to save the currently stored snapshot into. * The view argument. Which views to include. The supported views are: - with_runtimes_in_95th_percentile Based on the sys.statements_with_runtimes_in_95th_percentile view - analysis Based on the sys.statement_analysis view - with_errors_or_warnings Based on the sys.statements_with_errors_or_warnings view - with_full_table_scans Based on the sys.statements_with_full_table_scans view - with_sorting Based on the sys.statements_with_sorting view - with_temp_tables Based on the sys.statements_with_temp_tables view - custom Use a custom view. This view must be specified in @sys.statement_performance_analyzer.view to an existing view or a query Default is to include all except 'custom'. The procedure supports the following configuration options: * @sys.statement_performance_analyzer.limit The maximum number of rows to include for the views that does not have a built-in limit (e.g. the 95th percentile view has a built-in limit). If not set the limit is 100. * @sys.statement_performance_analyzer.view Used together with the 'custom' view. If the value contains a space, it is considered a query, otherwise it must be an existing view querying the performance_schema.events_statements_summary_by_digest table. There cannot be any limit clause including in the query or view definition if @sys.statement_performance_analyzer.limit > 0. If specifying a view, use the same format as for in_table. * @sys.debug Whether to provide debugging output. Default is 'OFF'. Set to 'ON' to include. For example to create a report with the queries in the 95th percentile since last truncate of performance_schema.events_statements_summary_by_digest and the delta for a 1 minute period: 1. Create a temporary table to store the initial snapshot. 2. Create the initial snapshot. 3. Save the initial snapshot in the temporary table. 4. Wait one minute. 5. Create a new snapshot. 6. Perform analyzis based on the new snapshot. 7. Perform analyzis based on the delta between the initial and new snapshots. mysql> CALL sys.statement_performance_analyzer('create_tmp', 'mydb.tmp_digests_ini', NULL); Query OK, 0 rows affected (0.08 sec) mysql> CALL sys.statement_performance_analyzer('snapshot', NULL, NULL); Query OK, 0 rows affected (0.02 sec) mysql> CALL sys.statement_performance_analyzer('save', 'mydb.tmp_digests_ini', NULL); Query OK, 0 rows affected (0.00 sec) mysql> DO SLEEP(60); Query OK, 0 rows affected (1 min 0.00 sec) mysql> CALL sys.statement_performance_analyzer('snapshot', NULL, NULL); Query OK, 0 rows affected (0.02 sec) mysql> CALL sys.statement_performance_analyzer('overall', NULL, 'with_runtimes_in_95th_percentile'); +-----------------------------------------+ | Next Output | +-----------------------------------------+ | Queries with Runtime in 95th Percentile | +-----------------------------------------+ 1 row in set (0.05 sec) ... mysql> CALL sys.statement_performance_analyzer('delta', 'mydb.tmp_digests_ini', 'with_runtimes_in_95th_percentile'); +-----------------------------------------+ | Next Output | +-----------------------------------------+ | Queries with Runtime in 95th Percentile | +-----------------------------------------+ 1 row in set (0.03 sec) ... sys.diagnostics(...) -------------------- The procedure will take three arguments: * 'in_max_runtime': The maximum runtime in seconds. - Range: 1 > INT UNSIGNED - Pass NULL to get the default of 60 seconds - A value > 0 is required * 'in_interval': The time between starting each iteration - Range: 1 > INT UNSIGNED - Pass NULL to get the default of 30 seconds - A sleep to wait for the next iteration will not start if the current run time plus the time between iterations exceeds the maximum runtime. * 'in_auto_config': The choice of the Performance Schema configuration to use: - Range: ENUM ('current', 'medium', 'full') - current: do not make any changes to the configuration - medium: enable all consumers except %_history and %_history_long and all instruments except wait/synch/% and all thread except the one monitoring - full: enable all consumers and all instrument + all threads except the one monitoring. Enabling additional instruments and consumers will in general have an impact on the performance of MySQL, so great care should be taken when using 'medium' and in particularly 'all'. The connection running the report will always be disabled for the duration of the procedure. The procedure supports the following configuration options: * @sys.diagnostics.allow_i_s_tables Set to 'ON' to include additional queries involving the information_schema.TABLES table. By default only a SELECT COUNT(*) is performed. * @sys.diagnostics.include_raw Set to 'ON' to include the output of the sys schema views at the start and end, and the sys.metrics (or equivalent) for each iteration. * @sys.debug Whether to provide debugging output. Default is 'OFF'. Set to 'ON' to include. * @sys.statement_truncate_len At which length to truncate statements in the sys.processlist output. For example to create a diagnostics report that starts an iteration every 30 seconds and runs for at most 60 seconds and using the current Performance Schema settings: CALL sys.diagnostics(60, 30, 'current'); I.e. this will execute a total of 2 iterations.
Copyright (c) 2000, 2024, Oracle Corporation and/or its affiliates. All rights reserved.