[MySQL データベース] 第 3 章の解釈: サーバー パフォーマンス分析 (パート 2)

ため息をつきます: DBA は実際にはカバーされていません

3.3.3 使用状況のパフォーマンス分析: 限定的です

3.4 断続的な問題の診断

システムが時々一時停止したり、クエリが遅くなったり、問題がシャドウイングされたりする場合は、テストを使用しないようにしてください問題を解決する間違った方法: 高リスク

3.4.1 単一クエリの問題またはサービスの問題

SHOW GLOBAL STATUS を使用

より高い頻度: 1 秒/回このコマンドを実行してデータを取得すると、問題はカウンターを通じて発生します

使用SHOW PROCESSLIST [参考] 実行中のスレッドを表示します

クエリログ

を使用して低速クエリを有効にし、グローバルなlong_query_time=0を設定し、すべての接続が新しい設定を採用していることを確認します(すべての接続をリセットする必要がある場合があります)スループットが突然低下した期間中のログについては、クエリは完了フェーズ中にスロー クエリ ログにのみ書き込まれました。

優れたツールでは、半分の労力で 2 倍の結果が得られます: tcpdump、pt- query-digest、Percona サーバー

見つかった問題を理解する

視覚化されたデータ: gnuplot /R (描画ツール)

gnuplot:

インストール いくつかのコマンド: 一般的なテクニック 入門チュートリアル 2 Gnuplot データの視覚化

推奨: 最初のものを使用する最初の 2 つの方法は、単純なシェル スクリプトまたは繰り返し実行されるクエリを通じて低コストで対話型です。 データを収集する

3.4.2 診断データを取得する

断続的な問題がある場合は、(問題が発生したときだけでなく) できるだけ多くのデータを収集します。発生する)

クリア: 1. 問題が発生したときを区別する方法があります: トリガー; 2. 診断データを収集するためのツール

診断トリガー

エラー: 問題が発生していない期間に大量の診断データが収集されます。時間の無駄です (これは前の内容と矛盾していません。よく読んでください)

検出ミス: 問題が発生した場合 データが収集されず、機会が逸された場合 収集を開始する前に、トリガーが本当に可能であることを確認してください。問題を特定します。 適切なトリガー:

通常のしきい値と比較できるいくつかの指標を見つけます。

適切なしきい値を選択します。 十分に高い (通常はトリガーされない)、高すぎない (問題が発生したときに見逃されない)。 )

推奨ツール pt-stalk 【参考】 【2】トリガー、特定の条件に設定して監視対象の変数を記録・設定する 閾値チェックの頻度

どのようなデータを収集するか

実行時間

:作業時間待機時間

必要な期間内に収集できるすべてのデータを収集してください

未知の問題の理由: 1. サーバーは大量の作業を実行する必要があり、その結果、大量の CPU 消費が発生します; 2. リソースの解放を待機しています

診断データを収集して理由を確認するためのさまざまな方法:

1. 分析レポート: 作業が多すぎるかどうかを確認します。ツール: TCP トラフィック モードの開始と終了の遅いクエリ ログを確認します

2. 待機分析: 大量の待機があるかどうか、GDB スタック トレース情報、show processlist、show innodb status を確認して、スレッドとトランザクションのステータスを観察します

結果データを解釈します

目的: 1. 問題は本当に起こったのか; 2. 明らかなジャンプの変更はありますか?

ツール:

oprofile サンプルをカウントすることでプロセス、関数、コードを分析するのに役立つパフォーマンス カウンター (パフォーマンス カウンター) を使用します。 CPUを占拠している「犯人」。例 【参考】

opreportコマンドはCPU使用率をプロセスレベル、関数レベルそれぞれで見る方法です

 samples |                            %|
-----------------------------------------------------
     镜像内发生的采样次数     采样次数所占总采样次数的百分比      镜像名称

opannotateコマンドはコードレベルでCPU使用率の統計を表示することができます

GDB:

最も一般的なのはLinux アプリケーション開発で使用されるデバッガは gdb (デバッグの対象は実行可能ファイル) で、プログラムにブレークポイントを設定したり、変数値を表示したり、プログラムの実行プロセス (データ、ソース コード) を段階的に追跡したりできます。メモリとスタックの情報を表示します。デバッガのこれらの機能を使用すると、プログラム内の文法以外のエラーを簡単に見つけることができます。 [参照] [参照] 構文と例

3.4.3 診断ケース

MySQL、innodb、GNU/Linux の関連知識を伴う断続的なパフォーマンスの問題

明確に: 1. 何が問題なのか、明確に説明されている。問題を解決するために何が行われましたか?

スタート

: 1. サーバーの動作を理解する; 2. サーバーのステータスパラメータを整理し、ソフトウェアおよびハードウェア環境を構成する (pt-summary pt-mysql-summary) 気を散らさないでください話題から逸れすぎたさまざまな状況で、紙に質問を書き、それぞれをチェックして取り消し線を消します

それは原因ですか、それとも結果ですか? ? ?

リソースが非効率になる考えられる理由: 1. リソースが過剰に使用されており、残高が不足しています。 2. リソースが正しく一致していません。 3. リソースが破損しているか、機能不全に陥っています。 3.5 その他のプロファイリング ツールUSER_STATISTICS : 一部のテーブルはデータベース アクティビティを測定および監査します

strace: システム コール、実際の時間の使用、予測不可能性、オーバーヘッドを調査します

oprofile

消費された CPU サイクルを使用します

概要:

最も効果的なパフォーマンスを定義します メソッドは応答時間です

測定できなければ、効果的に最適化することはできません。パフォーマンスの最適化作業は、高品質で包括的かつ完全な応答時間の測定に基づいて行う必要があります

測定の最良の出発点はアプリケーションです。問題が基礎となるデータベースにある場合でも、優れた測定の助けを借りて問題を見つけるのは簡単です

ほとんどのシステムは完全に測定することはできず、測定によっていくつかの制限を回避する方法を見つけることができます。そして、この方法の欠陥や不確実性にも注意してください

完全な測定では、分析が必要な大量のデータが生成されるため、プロファイラー (最良のツール) を使用する必要があります

プロファイリング レポート:情報はマスクされ、多くの詳細が破棄され、何が欠落しているのかを教えてくれません。

2 つの時間のかかる操作 (作業または待機) に完全に依存することはできません。ほとんどのプロファイラーは、作業に費やされた時間しか測定できません。待機中の共有は、特に CPU 使用率が低いにもかかわらず、作業が完了できない場合に役立つことがあります

最適化と改善は、継続的な改善のコストがメリットを上回る場合、最適化を停止する必要があります

。

データに基づいた直接的な思考回路、意思決定にできるだけ注意を払う

一言で言えば、 まず問題を明確にし、適切なテクノロジーを選択し、ツールをうまく活用し、十分に注意し、明確なロジックを持ち、それに固執してください。問題を特定する前に、原因と結果を混同しないでください。

関連記事:

[MySQL データベース]第 2 章の解釈: MySQL ベンチマーク テスト

[MySQL データベース] 第 3 章 解釈: サーバー パフォーマンス分析 (パート 1)

以上が[MySQL データベース] 第 3 章の解釈: サーバー パフォーマンス分析 (パート 2)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。