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

REDメソッドの紹介

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

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

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

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

です。

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

これらのメトリクスの健全性により、データベースのパフォーマンス、ひいてはユーザーのエクスペリエンスをしっかりと理解することができます。 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 の使用に関して考慮すべき一般的なガイドラインをいくつか示します:

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

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

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

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

7. スワップの使用法

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

理想的には、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 にアクセスすることを検討してください。