sql >> データベース >  >> RDS >> Mysql

SCUMMダッシュボードを使用したMySQLの効果的な監視：パート3

    以前のブログで、MySQL関連のダッシュボードについて説明しました。特に診断、メトリックレポート、および容量計画から日常業務を実行する場合に、グラフを調査することでDBAが恩恵を受けることができることを強調しました。このブログでは、InnoDBメトリックとMySQLパフォーマンススキーマについて説明します。これらは、特にInnoDBトランザクション、ディスク/CPU/メモリI/Oの監視、クエリの最適化、またはサーバーのパフォーマンス調整で非常に重要です。

    このブログは、InnoDBの内部に取り組む場合、InnoDBが広範囲にわたるカバレッジを必要とすることを考慮して、パフォーマンスの深いトピックに触れています。パフォーマンススキーマは、MySQLとストレージエンジンのカーネルとコア部分をカバーしているため、広範囲にわたっています。

    グラフを見ていきましょう。

    MySQLInnoDBメトリクス

    このダッシュボードは、InnoDBストレージエンジンの非常に優れたビューを提供するため、MySQLDBAまたは運用担当者に最適です。 MySQL構成で変数が正しく設定されているとは限らないため、ユーザーが有効にすることを検討する必要がある特定のグラフがここにあります。

    • Innodbチェックポイントの年齢

      マニュアルによると、チェックポイントは次のように定義されています。「バッファプールにキャッシュされているデータページに変更が加えられた場合 、これらの変更はデータファイルに書き込まれます しばらくして、フラッシングと呼ばれるプロセス 。チェックポイントは、最新の変更の記録です（ LSN で表されます） 値）データファイルに正常に書き込まれている 」。このグラフは、サーバーがディスクへのチェックポイントデータをどのように実行しているかを確認する場合に役立ちます。これは、トランザクションログ（redoログまたはib_logfile0）が大きすぎる場合に役立ちます。このグラフは、innodb_log_file_size 、、 innodb_log_buffer_size、innodb_max_dirty_pages_pct、innodb_adaptive_flushing_methodなどの変数を調整する必要がある場合にも役立ちます。チェックポイントの経過時間が最大チェックポイントの経過時間に近いほど、ログはいっぱいになり、InnoDBは、ログの空き領域を維持するために、より多くのI/Oを実行します。チェックポイントメカニズムは、Percona XtraDBベースのフレーバー、MariaDB、およびOracleのバージョン間で微妙な詳細が異なり、MySQLバージョン間の実装にも違いがあります。

    • InnoDBトランザクション

      MySQLサーバーで大規模なトランザクションが進行中の場合は常に、このグラフが参考になります。特定の時間に作成されたトランザクションをカウントし、履歴の長さ（または実際にはSHOW ENGINE INNODB STATUSにある履歴リストの長さ）は、取り消しログのページ数です。ここに表示される傾向は、たとえば、データの再読み込みの挿入率が非常に高いため、またはトランザクションが長時間実行されているためにパージが遅延している可能性があるかどうか、またはパージが単純に可能であるかどうかを確認するための優れたリソースです。 $DATADIRが存在するボリュームのディスクI/Oが高いため、追いついていない。

    • Innodb行操作

      特定のDBAタスクでは、削除、挿入、読み取り、および更新された行の数を確認したい場合があります。次に、このグラフを使用してこれらを確認できます。

    • Innodb行ロック時間

      このグラフは、アプリケーションで「ロック待機タイムアウトを超えました。ロック待機タイムアウトを超えました。トランザクションを再開してみてください 」。これは、ロックの処理に不正なクエリを使用する兆候があるかどうかを判断するのにも役立ちます。これは、行のロックを含むクエリを最適化するときに参照するのに適したリファレンスでもあります。待機時間が長すぎる場合は、遅いクエリログを確認するか、pt-query-digestを実行して、グラフでその肥大化を引き起こしている疑わしいクエリを確認する必要があります。

    • InnoDB I / O

      InnoDBデータの読み取り、ディスクフラッシュ、書き込み、およびログ書き込みの量を決定する場合は常に、このグラフに確認する必要があるものが含まれています。このグラフを使用して、InnoDB変数が特定の要件を処理するように適切に調整されているかどうかを判断できます。たとえば、Battery Backup Moduleキャッシュがあるが、最適なパフォーマンスがあまり得られていない場合は、このグラフを使用して、fsyncs（）が予想よりも高いかどうかを判断できます。次に、変数innodb_flush_methodを変更し、O_DSYNCを使用すると、問題を解決できます。

    • 1時間ごとのInnoDBログファイルの使用量

      このグラフは、InnoDB REDOログファイルに書き込まれたバイト数と、現在の日付の24時間の時間範囲に基づくInnoDBログファイルの増加のみを示しています。

    • InnoDBロギングパフォーマンス

      このグラフは、InnoDBログファイルの使用時間グラフと密接に関連しています。 innodb_log_file_sizeのサイズを決定する必要がある場合は、常にこのグラフを使用する必要があります。 InnoDB REDOログファイルに書き込まれるバイト数と、MySQLがメモリからディスクにデータをフラッシュする効率を決定できます。 REDOログスペースを使用する必要がある時間が少ない場合は、innodb_log_fileのサイズを増やす必要があることを示しています。その場合、このグラフはあなたがそうする必要があることをあなたに告げるでしょう。ただし、innodb_log_fileに必要な量をさらに掘り下げるには、SHOW ENGINE INNODB STATUSでLSN（ログシーケンス番号）を確認する方が理にかなっている場合があります。 Perconaには、これに関連する優れたブログがあり、これを参照するのに適した情報源です。

    • InnoDBデッドロック

      アプリケーションクライアントでデッドロックが頻繁に発生している特定の状況や、MySQLでデッドロックが発生している量を確認する必要がある場合、このグラフが目的を果たします。デッドロックは、SQLの設計が不十分であり、トランザクションが競合状態を引き起こしてデッドロックが発生することを示しています。

    • インデックス条件のプッシュダウン

      このグラフを見るときの注意点。まず、MySQLグローバル変数innodb_monitor_enableがmodule_icpという正しい値に設定されていることを確認する必要があります。それ以外の場合は、以下に示すように「データポイントなし」が発生します。

      グラフの目的は、サンプル出力にあるものとして定義されたデータポイントがある場合、DBAに、クエリがインデックス条件プッシュダウンまたは略してICPでどれだけ効果があるかを見落とすことになります。 ICPは、クエリに最適化を提供するMySQLの優れた機能です。 MySQLは、取得時にWHEREクエリでフィルタリングされた行全体を読み取る代わりに、セカンダリインデックスの後にチェックを追加します。これにより、粒度が向上し、時間が節約されます。そうしないと、フィルター処理されたインデックスのみに基づいており、ICPが使用されていない場合、エンジンは代わりにテーブル全体の行を読み取る必要があります。これにより、セカンダリインデックスに一致するインデックスタプルに対応する行全体が読み取られなくなります。

      このグラフについて少し詳しく説明します。たとえば、次の名前のテーブルがあるとします。

      mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

      そして、いくつかの小さなデータがあります：

      mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)

      ICPを有効にすると、結果がより効率的かつ実現可能になります。

      mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)

      ICPなしよりも

      mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)

      これはICPの簡単な例であり、このグラフがDBAにどのように役立つかを示しています。

    • InnoDBバッファープールコンテンツ

      MySQLを使用してInnoDBエンジンを使用する場合、このグラフは、MySQLのパフォーマンスを最適化するために調整する必要がある最も一般的な値（innodb_buffer_pool *）の1つです。具体的には、バッファプールのコンテンツについて言えば、バッファプールのコンテンツ全体に対するダーティページの傾向が表示されます。バッファプールの合計コンテンツには、ダーティページ以外のクリーンページが含まれます。 MySQLがバッファプールをどれだけ効率的に処理しているかを判断するこのグラフは、その目的を果たします。

    • InnoDBバッファープールページ

      このグラフは、MySQLがInnoDBバッファープールをどの程度効率的に使用しているかを確認する場合に役立ちます。このグラフを使用できます。たとえば、毎日のトラフィックが割り当てられたinnodb_buffer_pool_sizeを満たしていない場合、これは、アプリケーションの特定の部分が役に立たないか、目的を果たさないこと、またはinnodb_buffer_pool_sizeを非常に高く設定したことを示している可能性があります。これは、値を下げてメモリにスペースを取り戻すのに良いかもしれません。

    • InnoDBバッファープールI/O

      InnoDBテーブルで作成および書き込まれたページ数、またはInnoDBテーブルでの操作によるInnoDBバッファープールへのページ読み取り数を確認する必要がある場合。

    • InnoDBバッファープールリクエスト

      クエリがInnoDBバッファープールにどれだけ効率的にアクセスしているかを判断したい場合は、このグラフが目的に役立ちます。このグラフは、InnoDBエンジンがディスクに頻繁にアクセスする必要がある場合（バッファープールの表示がまだウォームアップされていない場合）のMySQLサーバーのパフォーマンス、バッファープール要求が読み取り要求と書き込みを処理する頻度に関するデータポイントに基づく傾向を示します。リクエスト。

    • InnoDB先読み

      変数innodb_random_read_aheadをONに設定したら、このグラフをDBAルーチンの一部として見る価値のあるトレンドとして追加します。これは、MySQL InnoDBストレージエンジンが先読みバックグラウンドスレッドによってバッファープールを管理する方法、クエリによってアクセスされることなくその後削除されたバッファープールを管理する方法、およびクエリがスキャンしたときにInnoDBがランダム先読みを開始する方法の傾向を示しています。テーブルの大部分ですが、ランダムな順序です。

    • InnoDB変更バッファー

      Percona Server 5.7を実行している場合、このグラフは、InnoDBが変更バッファリングをどの程度適切に割り当てているかを監視するときに役立ちます。この変更には、innodb_change_buffering変数で指定された挿入、更新、および削除が含まれます。変更バッファリングはクエリを高速化し、ディスクからセカンダリインデックスページを読み込むために必要となる実質的なランダムアクセスI/Oを回避します。

    • InnoDB変更バッファアクティビティ

      これはInnoDBChangeBufferグラフに関連していますが、情報をより実行可能なデータポイントに分析します。これらは、InnoDBが変更バッファリングを処理する方法を監視するための詳細情報を提供します。これは、変更バッファリングがInnoDBバッファプールの同じメモリを共有し、データページのキャッシュに使用できるメモリを減らすため、innodb_change_buffer_max_sizeが高すぎる値に設定されているかどうかを判断する特定のDBAタスクで役立ちます。ワーキングセットがバッファプールにほぼ収まる場合、またはテーブルにセカンダリインデックスが比較的少ない場合は、変更バッファリングを無効にすることを検討する必要があります。変更バッファリングは、バッファプールにないページにのみ適用されるため、余分なオーバーヘッドは発生しないことに注意してください。このグラフは、特定のシナリオの特定の要求に基づいてアプリケーションのベンチマークを行う必要がある場合に、マージがどのように役立つかを判断する必要がある場合にも役立ちます。一括挿入があるとすると、innodb_change_buffering =insertを設定し、バッファプールとinnodb_change_buffer_max_sizeに値を設定しても、特にリカバリ中または低速シャットダウン中にディスクI / Oに影響がないかどうかを判断する必要があります（低ダウンタイム要件のフェイルオーバー）。また、更新するセカンダリインデックスが多数あり、影響を受ける行が多い場合、変更バッファーのマージには数時間かかることがあるため、このグラフは特定のシナリオを評価する目的に役立ちます。この間、ディスクI / Oが増加するため、ディスクにバインドされたクエリの速度が大幅に低下する可能性があります。

    MySQLパフォーマンススキーマ

    MySQLパフォーマンススキーマは複雑なトピックです。長くて難しいものですが、SCUMMにあるグラフに固有の情報についてのみ説明します。考慮しなければならない特定の変数もあり、それらが適切に設定されていることを確認してください。グラフにデータポイントを表示するには、変数innodb_monitor_enable=allおよびuserstat=1があることを確認してください。注意として、ここで「イベント」という言葉を使用している場合、これがMySQLEventSchedulerに関連していることを意味するわけではありません。 MySQLがクエリを解析する、MySQLがリレー/バイナリログファイルの読み取りまたは書き込みを行うなど、特定のイベントについて話しています。

    それではグラ​​フを進めましょう。

    • パフォーマンススキーマファイルIO（イベント）

      このグラフは、インストルメント化されたオブジェクトの複数のインスタンスを作成するためにインストルメント化された可能性のあるMySQLで発生したイベントに関連するデータポイントをフェッチします（例：バイナリログ読み取りまたはInnoDBデータファイル読み取り）。各行には、特定のイベント名のイベントが要約されています。たとえば、接続ごとに作成されるミューテックスのインストルメントがある場合、複数の接続があるため、このインストルメントされたイベントのインスタンスが多数存在する可能性があります。機器の要約行は、これらすべてのインスタンスを要約します。詳細については、MySQLマニュアルのパフォーマンススキーマサマリーテーブルでこれらのイベントを確認できます。

    • パフォーマンススキーマファイルIO（ロード）

      このグラフは、負荷に基づいて計測されることを除いて、「パフォーマンススキーマファイルIO（イベント）」グラフと同じです。

    • パフォーマンススキーマファイルIO（バイト）

      このグラフは、バイト単位のサイズに基づいて計測されることを除いて、「パフォーマンススキーマファイルIO（イベント）」グラフと同じです。たとえば、MySQLがwait / io / file / innodb/innodb_data_fileイベントをトリガーしたときに特定のイベントにかかった時間。

    • パフォーマンススキーマ待機（イベント）

      このグラフには、特定のイベントに費やされたすべての待機のデータグラフが含まれています。詳細については、マニュアルの待機イベントの概要表を確認してください。

    • パフォーマンススキーマ待機（ロード）

      「パフォーマンススキーマ待機（イベント）」グラフと同じですが、今回は負荷の傾向を示しています。

    • インデックスアクセス操作（ロード）

      このグラフは、wait / io / table / sql / handlerインスツルメントによって生成された、テーブルのインデックスごとにグループ化されたすべてのテーブルインデックスI/O待機イベントの集計です。詳細については、パフォーマンススキーマテーブルtable_io_waits_summary_by_index_usageに関するMySQLマニュアルを確認できます。

    • テーブルアクセス操作（ロード）

      「インデックスアクセス操作（ロード）」グラフと同じです。これは、wait / io / table / sql / handlerインスツルメントによって生成された、テーブルごとのすべてのテーブルI/O待機イベントの集計です。これはDBAにとって非常に便利です。たとえば、特定のテーブルへのアクセス（フェッチ）または更新（挿入、削除、更新）にかかる時間を追跡したいとします。詳細については、MySQLのマニュアルでパフォーマンススキーマテーブルtable_io_waits_summary_by_tableを確認できます。

    • パフォーマンススキーマSQLと外部ロック（イベント）

      このグラフは、テーブルごとにグループ化されたwait / lock / table / sql / handlerインスツルメントによって生成された、すべてのテーブルロック待機イベントの集計（発生した回数のカウント）です。ここでのグラフのSQLロックは、内部ロックを意味します。これらの内部ロックは、通常の読み取り、共有ロックを使用した読み取り、高優先度の読み取り、挿入なしの読み取り、書き込み許可書き込み、同時挿入の書き込み、書き込み遅延、低優先度の書き込み、通常の書き込みです。外部ロックが外部で読み取られ、外部で書き込まれている間。 DBAタスクでは、タイプに関係なく特定のテーブルのロックをトレースおよび調査する必要がある場合に、これは非常に役立ちます。詳細については、テーブルtable_lock_waits_summary_by_tableを確認してください。

    • パフォーマンススキーマSQLと外部ロック（秒）

      グラフ「パフォーマンススキーマSQLと外部ロック（イベント）」と同じですが、秒単位で指定されます。ロックを保持した秒数に基づいてテーブルロックを検索する場合は、このグラフが適しています。

    結論

    InnoDBメトリクスとMySQLパフォーマンススキーマは、特に解釈を支援する視覚化がない場合、MySQLドメインで最も詳細で複雑な部分の一部です。したがって、手動のトレースと調査に進むと、時間と労力がかかる場合があります。 SCUMMダッシュボードは、これらを処理し、DBAルーチンタスクの余分な負荷を軽減するための非常に効率的で実行可能な方法を提供します。

    このブログでは、InnoDBとパフォーマンススキーマのダッシュボードを使用してデータベースのパフォーマンスを向上させる方法を学びました。これらのダッシュボードを使用すると、パフォーマンスの分析をより効率的に行うことができます。


    1. AzureSQLデータベースでの自動インデックス管理

    2. 非推奨：mysql_connect（）

    3. 1つの状況を除いて、テーブルの更新を防ぐ方法

    4. 時間とステータスの列からステータス値ごとの分にトランザクションデータを正規化します