MySQL をマスターする: すべての開発者が監視すべき主要なパフォーマンス指標

MySQL パフォーマンス メトリクスの監視とデータベースの管理は、難しい必要はありません。はい、そうですよね。適切な監視戦略とツールを自由に使えるようになると、ようやく後回しにできるようになります。 RED メソッドは、Releem の強力な監視機能と適用しやすい構成の推奨事項と組み合わせて、面倒な作業を自動的に実行します。

REDメソッドの紹介

RED メソッドは従来、Web アプリケーションとサービスのパフォーマンスを監視するために使用されてきましたが、MySQL のパフォーマンス監視にも適用できます。 Releem は、パフォーマンスと信頼性の点でデータベースが直面する課題は、Web アプリケーションが直面する課題を反映しているため、このフレームワークは MySQL のパフォーマンス メトリクスを監視する上でも同様に価値があると考えています。

RED メソッドを MySQL データベースに適用すると、次の 3 つの重要な懸念領域に分類され、それぞれがデータベースの運用状態に関する洞察を提供します。

• クエリ レート (レート) – 1 秒あたりに実行されるクエリまたはコマンドの量を評価し、サーバーのワークロードを直接測定します。これは、データベースの同時操作の処理能力とユーザーの要求への応答性を評価するのに役立ちます。

• エラー率 (エラー) – クエリ内のエラーの頻度を追跡することで、データベース内の潜在的な信頼性の問題が明らかになります。エラー率が高い場合は、データベース全体の整合性に影響を与えている、クエリ構文、データベース スキーマ、またはシステム制約に関する根本的な問題を示している可能性があります。監視レートの主要な MySQL メトリクスは Aborted_clients.

です。

• クエリ実行期間 (Duration) – 期間メトリックは、クエリの開始から実行までの完了にかかる時間の尺度です。このパフォーマンス指標は、ユーザー エクスペリエンスとシステム スループットに直接影響を与えるデータの取得と処理操作の効率を評価します。

これらのメトリクスの健全性により、データベースのパフォーマンス、ひいてはユーザーのエクスペリエンスをしっかりと理解することができます。 RED メソッドを使用すると、データベースの何が問題で、何を修正する必要があるかを簡単に判断できます。たとえば、クエリの実行が遅いと感じた場合は、インデックスを調整したり、影響を受けるクエリを最適化して効率を高める必要があることを示している可能性があります。

RED メソッドに不可欠な 8 つの MySQL パフォーマンス メトリクス

RED メソッドを MySQL パフォーマンス監視に効果的に適用するために、Releem はデータベースの 8 つの重要な側面に焦点を当てます。これらはそれぞれ、何らかの方法でレート、エラー、または期間に関連付けられています。

1. MySQL のレイテンシ

レイテンシは、クエリがデータベースに送信された瞬間からデータベースが応答するまで、クエリの実行にかかる時間を測定します。レイテンシは、ユーザーがアプリケーションをどのように認識するかに直接影響します。

ほとんどの Web アプリケーションでは、データベース操作で数ミリ秒から最大約 10 ミリ秒の範囲の遅延を達成することが優れていると考えられます。この範囲では、遅延がエンド ユーザーにとって実質的に知覚できないため、シームレスなユーザー エクスペリエンスが保証されます。

単純なクエリから中程度に複雑なクエリまでの遅延が 100 ミリ秒のマークに達すると、ユーザーは遅延に気づき始めます。これは、フォームの送信、検索クエリ、動的コンテンツの読み込みなど、即時のフィードバックが重要な場合に問題になる可能性があります。

MySQL レイテンシの詳細

2. スループット

スループットは 1 秒あたりのクエリ数 (QPS) として定量化され、データベースの効率とワークロードを管理する能力を測定します。高いスループットは、大量のクエリを効率的に処理できる、適切に最適化されたデータベース システムを意味します。スループットが低い場合は、パフォーマンスのボトルネックまたはリソースの制限を示している可能性があります。

高スループットを達成するには、通常、最適化された SQL クエリ、適切なハードウェア リソース (CPU、メモリ、高速 IO サブシステム)、および微調整されたデータベース構成の組み合わせが必要です。

スループットの詳細

3. 遅いクエリの数

遅いクエリは基本的に、事前に定義された実行時間のしきい値に違反するデータベース リクエストです。このしきい値は、特定のパフォーマンス目標や運用ベンチマークに合わせて調整できます。遅いクエリの数を追跡することは、最適化が必要なクエリを特定する方法です。

これらの遅いクエリの識別とログは、設定されたパフォーマンス標準を満たしていないクエリの詳細を保存するために作成された専用ファイルである、slow_query_log で行われます。

スロークエリ数の詳細

4. 中止されたクライアント

このメトリクスは、クライアントが接続を適切に閉じなかったために中止された接続の数をカウントします。中止されたクライアントの数が多い場合は、さまざまな原因が考えられます:

• タイムアウトを引き起こすネットワーク遅延とジッター
• サーバーの容量制限により接続が拒否される
• クエリ間のリソース競合
• 長時間実行されるクエリによる非効率
• MySQL 設定の構成ミス
• アプリケーションエラーにより早期切断が引き起こされる

中止されたクライアントの詳細

5. CPU使用率

CPU はサーバーの頭脳です。コマンドを実行し、データベースでデータを保存、取得、変更、削除できるようにする計算を実行します。 CPU 使用率を注意深く監視すると、サーバーがワークロードを処理するのに十分な処理能力を確保できるようになります。 CPU 使用率が高い場合は、過負荷状態のサーバーが、サーバーに課せられた要求に対応するのに苦労していることを示す明らかな兆候である可能性があります。

CPU 使用率に関して考慮すべき一般的なガイドラインは次のとおりです。

• 50-70% 持続 – このレベルでは、CPU は中程度から重いワークロードを効果的に処理していますが、ピーク負荷に対してはまだ余裕があります。これは、通常の運用におけるサーバーの健全な範囲です。

• 70 ～ 90% が持続 – CPU 使用率が一貫してこの範囲内にある場合、ワークロードが高く、ピーク要求を処理する余地が限られていることを示します。サーバーを注意深く監視する必要があります。

• 90% 以上が継続 – これは、サーバーが限界に近づいているか、限界に達していることを示す強力な指標です。クエリの応答時間の遅さやタイムアウトの可能性など、顕著なパフォーマンスの問題が発生する可能性があります。原因を調査し、最適化を実装するか、それに応じてリソースをスケールすることが重要です。

注: データベースは変動する負荷を処理するように設計されているため、これらのしきい値を超えるスパイクが時折発生しても、必ずしも問題を示しているわけではありません。キーワードは持続します。継続的な使用率が高い場合は、サーバーに大きな負荷がかかっていることを示しています。

6. RAMの使用量

RAM はデータベースにとって重要なリソースであり、アクティブなデータとインデックスを保存し、迅速なアクセスと効率的なクエリ処理を可能にします。 RAM 使用量を適切に管理することで、データベースがワークロードを効率的に処理できるようになり、データの取得と操作の両方の操作が最適化されます。

RAM の使用に関して考慮すべき一般的なガイドラインは次のとおりです。

• <60-70% 使用率 – この範囲は一般に安全とみなされ、現在のデータベース操作と追加のワークロードのスパイクの両方に使用できる十分なメモリがあることを示します。

• 70-85% 使用率 – RAM 使用率が一貫してこの範囲内にある場合、データベースは使用可能なメモリを有効に活用しているものの、注意深く監視するためのしきい値に達し始めていることを示しています。 。ピーク時にこの範囲に留まると、需要の突然の増加に対応するためのバッファーが制限される可能性があります。

• 85 ～ 90% 使用率 – この範囲では、サーバーのメモリ容量が近づいています。メモリ使用率が高いと、システムがディスクとの間でデータのスワップを開始するため、ディスク I/O が増加する可能性があります。これは、ワークロードを最適化する必要があるか、サーバーの物理メモリを拡張する必要があることを示す警告サインであると考えてください。

• > 95% 使用率 – 95% 以上の RAM 使用率で動作させることは重要であり、パフォーマンスの問題を引き起こす可能性があります。このレベルでは、サーバーは頻繁にスワップに頼る可能性があり、深刻な速度低下を引き起こし、クライアント アプリケーションのタイムアウトを引き起こす可能性があります。お客様側で直ちに対応する必要があります。

7. スワップの使用法

SWAP スペースは、DB の物理 RAM が完全に利用されている場合に使用され、システムがアクセス頻度の低いデータの一部をディスク ストレージにオフロードできるようにします。このメカニズムはメモリ不足エラーに対するバッファーとして役立ちますが、SWAP に依存すると、アクセス時間が RAM に比べて大幅に遅いため、パフォーマンスに重大な影響を与える可能性があります。

理想的には、MySQL サーバーの SWAP 使用量は低いか最小限である必要があります。これは、データベースが利用可能な RAM 内で動作していることを示します。

SWAP の使用率が高い場合は、サーバーの物理メモリがワークロードに対して不十分であり、日常的なデータ操作をディスク領域に依存せざるを得なくなっていることを示す危険信号です。アプリケーションのメモリ要求を最適化するか、サーバーの RAM をスケールアップすることで、この問題に対処するための措置を直ちに講じる必要があります。

8. 1 秒あたりの入出力操作数 (IOPS)

1 秒あたりの入出力操作数 (IOPS) メトリクスは、データベースが基盤となるストレージ システム (ディスクとも呼ばれます) とどの程度集中的に対話するかを示します。 IOPS のレベルが高いということは、ストレージ メディアとの間で転送されるデータの負荷が高いことを示しており、データベースがビジー状態であることを示している一方で、ディスク パフォーマンスの潜在的なボトルネックも浮き彫りになる可能性があります。

IOPS に影響を与える主な要素には次のものがあります。

• ストレージ メディアの種類。通常、SSD は HDD よりも速度が優れています
• 読み取りまたは書き込み操作を最適化できる RAID 構成
• 読み取りが多いか書き込みが多いかに関係なく、データベース ワークロードの特定の要求
• 同時実行性のレベルとキャッシュ戦略の有効性

リリームのデータベース管理の総合戦略

MySQL パフォーマンス監視に対する Releem のアプローチは、重要な詳細を常に監視することです。この戦略には、前述の 8 つの指標 (MySQL レイテンシ、スループット、遅いクエリ、中止されたクライアント、CPU、RAM、SWAP 使用量、IOPS) の熱心な追跡が含まれており、すべて RED メソッドのフレームワーク内で行われます。このモニタリングを 1 日 2 回のヘルス チェック (19 メトリクス!) の一部として統合することで、Releem はデータベースが高レベルのパフォーマンス、信頼性、およびスケーラビリティを達成および維持できるように支援します。

Releem は、MySQL のパフォーマンスを監視するだけでなく、監視中に発見された問題を修正することを目的とした、カスタマイズされた構成の提案を提供することでさらに一歩進んでいます。この機能を MySQL の Autopilot と呼びます。たとえば、レイテンシが高いという問題が発生している場合、Releem はレイテンシの数値を正常な状態に戻すための実用的な洞察を提供します。私たちの最終的な目標は、心配したくないデータベース管理のすべての複雑さを処理する強力で直感的なソフトウェアを使用して、手動による監視の必要性を取り除くことです。

Releem には幅広い互換性があるため、データベース管理システムに Percona、MySQL、または MariaDB を使用している場合でも、Releem が役に立ちます。サポートされているシステムの公式リストはこちらでご確認ください。

各メトリックの詳細と、MySQL データベースの監視と最適化のベスト プラクティスについては、Releem.com へのアクセスを検討してください。

以上がMySQL をマスターする: すべての開発者が監視すべき主要なパフォーマンス指標の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。