データベース

CloudLinux MySQL Governor：データベースの負荷をスマートに制限

CloudLinux MySQL Governorは、アカウントごとのデータベース負荷を制限し、それを公平に分散させることで、個々のクエリがホスティング全体を遅くすることがないようにします。私はこの MySQL ガバナー, 、ユーザーごとのCPU、READ、WRITEをリアルタイムで監視し、上限を超えた場合に自動的に制限をかけるため。.

中心点

アカウントごと グローバルな制限の代わりに
CPU/読み取り/書き込み 個別に制御する
モード 「Monitor-only」と「Abusen」

LVE

CLIツール 確認用

なぜ個々のクエリが全体の処理を遅らせるのか

共有ホスティング環境では、通常、生成されるのはごくわずかな クエリ データベースの量ではなく、負荷の大部分です。誤ったクエリやI/O負荷の高いプラグインが、突然CPU時間を独占し、他のユーザーにとって遅延が顕著に増加するケースをよく目にします。まさにここで、知事この指標を採用しているのは、ユーザーごとの負荷を可視化し、単なる全体平均だけを見るのではなく、個々の状況を把握できるからです。これにより、他のプロジェクトのワークロードが健全であるにもかかわらず、「騒がしい隣人」によって他のすべてのプロジェクトが停滞してしまうのを防ぐことができます。明確な閾値と公平な負荷分散により、応答時間を予測可能な範囲に保ち、過度なアクセスによる影響を未然に防いでいます。.

MySQL Governorの日常的な動作

私はよく モニター-onlyモードを使用して、介入することなく実際の利用状況を測定します。その後、アブーズモードを有効にします。このモードでは、過剰なアカウントを自動的に制限された環境に移行させ、その影響を即座に抑制します。測定は以下に基づいて行われます。 スレッド- MySQL/MariaDB接続ごとの統計情報により、ユーザーごとのCPU使用率、読み取りおよび書き込みの割合を把握できます。過負荷が継続する場合、割り当てられたLVEが追加で発動し、当該アカウントのプロセスがさらに抑制されます。この2段階のプロセスにより、事態の悪化を防ぎ、ピーク負荷を緩和し、関係のないプロジェクトを確実に保護します。.

閾値と時間枠を適切に設定する

私は複数の項目にわたって制限を設けています インターバル, 、これにより、一時的なピークは許容しつつ、持続的な過負荷は確実に阻止できるようにするためです。短時間の期間については上限を高く設定し、中程度の期間については適度に、長期間については明らかに厳しく設定し、いずれもグローバルなLVE制限値を下回るようにする必要があります。CPUの使用率は、パーセンテージとしてコア; 8コアの場合、100%は1コア分に相当するため、負荷分散と公平性が透明に保たれます。READとWRITEについては、ストレージへの実際の負荷を把握できるよう、キャッシュヒットを排除した実際のディスクI/Oに基づいて評価しています。全体的な構成を適切に整えるため、実績のあるLVEルールや、以下の詳細を参考にしています。 LVEの制限値を正しく設定すると説明した。

時間帯やプロファイルに応じたインターバルの計画

喜んで預かります 時間帯に応じたプロファイル: ピーク時間帯には、正当なトラフィックの急増（例：オンラインショップのフラッシュセールなど）に対応できるよう、短いインターバルの許容範囲を少し広めに設定しています。夕方から夜にかけては、特に 長い間隔 より厳格に設定し、長時間実行されるジョブが気づかれないうちにディスク容量を使い果たすのを防ぎます。バッチウィンドウについては、WRITEを少し多めに設定しつつCPU使用量を制限した独自のプロファイルを定義しています。これにより、インポート処理は迅速に行われつつも、リソースを独占することはありません。重要なのは、すべての設定を同時に変更しないことです。まずCPUを調整して状況を観察し、次にREAD/WRITEを調整します。変更ごとに明確な観察期間を設けることで、原因と結果を明確に区別できるようにしています。.

CLIツールと迅速な診断

私は、不審な口座を以下の方法で分析しています。 dbtop リアルタイムで、dbctl を使って制限値を更新し、lveinfo –dbgov を使って過去の履歴を確認します。これらのツールを使えば、ピーク値、長時間実行されているクエリ、ユーザーごとの接続数に関する重要な情報を数秒で把握できます。これにより、特に CPU あるいはI/Oの制限、接続数が膨れ上がっているか、あるいは個々のテーブルでクエリが滞留しているかなどを確認します。これらのパターンから、各インターバルごとに適切な閾値を導き出し、まずは「監視のみ」モードで変更をテストします。グラフの推移が妥当な水準まで低下してから、初めて制限を恒久的に有効にします。.

工具	目的	例
dbtop	ユーザー／スレッドごとのライブビュー	dbtop –by-user
dbctl	制限の設定とモードの制御	dbctl set userX cpu=120 read=8 write=6
lveinfo –dbgov	履歴と違反の確認	lveinfo –dbgov –id userX –period 1h

トラブルシューティング：典型的なパターンと迅速な対処法

いつ CPU アカウントのパフォーマンスが急上昇している場合、SELECT * のような記述、WHERE 句の欠如、大規模な結果セットを伴う複雑な ORDER BY、あるいは ORM による N+1 クエリといったパターンをよく見かけます。 I/Oに関しては、適切なインデックスがない状態でのフルスキャン、繰り返される「LIKE ‚%…%‘」といったクエリ、あるいはインデックスが設定されていない列に対するJOINが見受けられます。私の対応手順は、影響を受けるテーブルを特定し、クエリプランを確認し、不足しているインデックスを追加し、クエリを 合理化する （必要な列のみ、LIMIT/OFFSET またはカーソル方式によるページネーション）。並行して、このユーザーに対して一時的に、より厳しい 短い間隔, 、ピークを直ちに緩和するため、そして修正が本番環境で適用され、曲線が安定して下降し始めたら、再び締め付けを緩めてください。.

LVEとの連携：2段階のチェック

私はMySQL Governorを次のように捉えています。第一データベース保護レイヤーとLVEは、負荷が長期間続く場合の「第2のブレーキ」として機能します。ガバナーはデータベースのアクティビティを的確に抑制する一方、LVEはさらに、アカウント全体のCPU、RAM、IOを厳格に管理します。この組み合わせにより、短いクエリを繰り返し実行するだけでアカウントが制御不能になるのを防ぎます。それでもアクティビティが高い状態が続く場合は、 LVE そして、そのアカウントのプロセス優先度を下げることで、データベースの負荷を著しく軽減します。これにより、負荷の急増やトラフィックのピーク時であっても、すべての顧客に対して安定したサービス品質を維持できます。.

実務における基準値：例示値

一般的な共有サーバーでは、次のように開始します。 CPU-アカウントごとのリミットを、短期的な間隔では80～150%に設定し、長期的な間隔では大幅に引き下げます。 READ/WRITEについては、短期的には4～12 MB/sから始め、長期的にはディスクが恒常的な待機状態に陥らないよう、制限を厳しくしています。同時接続数については、 30, 、というのも、接続数が過剰になるとスレッドプールがすぐに枯渇してしまうからです。こうした初期値は目安としては適していますが、私はdbtopやlveinfoから得られる実際のログに基づいて調整しています。重要なのは、一時的なピークは許容する一方で、持続的なリソースの限界状態は徹底的に防ぐということです。.

例外、ホワイトリスト、およびメンテナンス期間

一部の口座は、時期によっては余裕が必要になる：大規模な輸入, 、ショップの移行、再インデックス。私はこうした作業を、主要な利用時間帯を避けた時間帯に計画し、事前にユーザーごとの上限を一時的に引き上げておきます。完了後は、スクリプトを使って標準値に戻します。同様に有効なのは、小さな ホワイトリスト システム上重要なアカウント（例：内部サービスユーザーなど）については、決して帯域制限を行わないようにしています。例外が発生した場合は、開始時刻・終了時刻および目標値を記録し、後日の分析でその逸脱の原因を解明できるようにしています。これにより、正当なメンテナンス作業を妨げることなく、ガバナンスの透明性を確保しています。.

WordPressとプラグイン：よくあるトラブルの原因を解消する

CMSのセットアップでは、高価な ジョインズ, 、キャッシュのない動的なウィジェットや、1時間ごとにテーブル全体をスキャンするcronジョブなどです。ガバナーはここで確実に保護してくれますが、私はさらにアプリケーション側でも根本原因を解決しています。オブジェクトキャッシュを有効にし、検索クエリを減らし、適切な場所ではコネクション・プーリング, 、接続／切断の急増を防ぐためです。明確なCPU／I/O制限と組み合わせることで、応答時間を著しく短縮し、負荷管理しやすい。この組み合わせにより、サポートチケットの数を減らし、サーバーに負荷がかかる前にトラフィックのピークを緩和することができます。.

実務におけるスキーマとインデックスのメンテナンス

テーブルやインデックスがまだ アクセスパターン 適合する。新しい機能やプラグインによって、クエリはしばしば微妙に変化する。フィルタが1つ追加されたり、並べ替え基準が変わったりするだけで、既存のインデックスが機能しなくなってしまう。そのため、私は頻繁に使用されるWHERE句の列に対してインデックスを優先的に作成し、 重複する指数 また、LIKEプレフィックス検索を、より的確なフィールド検索に置き換えます。アーカイブテーブルについては、パーティションの概念やタイムスタンプフィルターを活用し、フルスキャンを回避しています。ガバナーは不適切なスキーマによる影響を緩和しますが、最も効率的なのはデータを アクセスしやすい を体系化する。.

接続管理：500エラーを回避する

同時接続数が多すぎると、サービスが頻繁にダウンしてしまう タイムアウト, 、これらは500エラーとして表示されます。まず、ユーザーごとの接続レートとスレッドプールの使用率を確認します。接続の急増の兆候が見られる場合は、制限を厳しく設定し、クエリレベルまたはオブジェクトレベルでのキャッシュを導入します。補足として、以下の記事で詳しく説明しています。接続に起因する500エラーこのボトルネックの典型的な原因と対策。総じて、MySQLスタックの安定性を確保し、 レイテンシー 予測可能だ。

プーリングとキープアライブの適切な調整

プールのサイズ設計を行っています 規模は小さいが、安定している: 典型的な並行処理をカバーするのに十分な長さであり、アイドル状態のセッションによってサーバーがブロックされることを防ぐ。キープアライブ時間を長く設定すると負荷のピークを平準化できるが、多数の休眠中の接続がリソースを占有することになってはならない。そのため、アカウントごとの滞在時間とアイドル時間を測定し、それに応じてプールサイズやセッションタイムアウトを調整しています。ガバナーと組み合わせることで、接続の無秩序な確立・切断によるCPU負荷の増加を防ぎつつ、同時に過剰なプールサイズがスレッドプールを不必要に占有する事態も回避しています。.

モニタリング指標の正しい読み方

私は次の2つを明確に区別している。 CPU また、I/Oについても同様です。これら2つのリソースは、ボトルネックとなる仕組みが全く異なるからです。適切なI/O値がないままCPU使用率が急上昇した場合、多くの場合、ロジックやパーシング、あるいは非効率的な実行計画が原因で処理がブロックされます。一方、I/O使用率が高くCPU使用率が低い場合は、フルスキャンやインデックスの欠如がボトルネックの原因となっている可能性があります。 READ/WRITEについては、常にキャッシュを除外して評価しています。これにより、単なるメモリアクセスではなく、実際のディスク負荷を把握できるようにするためです。さらに、接続時間、アクティブなスレッド数、クエリの長さを確認し、処理が遅いクエリを早期に特定します。これらのパターンから、どの閾値を設定し、どの間隔をより厳しく調整すべきかが判断できます。.

ハードウェアおよびエンジンの要因を考慮する

仝 ストレージクラス どの閾値が現実的かを決定します。NVMeでは短期的にはより高いREAD/WRITE値を許容できますが、HDDではより保守的な計画を立て、長い間隔における制限を厳格に設定しています。また、エンジンのバッファリング方法にも注意を払っています。アグレッシブなバックグラウンドライターはピークを平滑化できますが、一見「静かな」フェーズを生み出し、その間に書き込みが後れを取ることもあります。そのため、ガバナーのメトリクスと物理I/O、およびブロックデバイスでの待ち時間を相関させて分析しています。目標は常に、 より安定した レイテンシを犠牲にして、最大スループット値ではなく中央値を採用する。.

「Monitor-only」と「Abusen」の比較

私は モニター-onlyモードを使用して、実際の利用プロファイルを収集し、ベースラインを導き出します。妥当な閾値を設定したら、Abusenモードに切り替えて、ガバナーが過負荷状態のアカウントを自動的に制限するようにします。前者のモードは誤検知を減らし、後者は実際のピーク時の巻き添え被害を防ぎます。経験に応じて、長い間隔ではより厳格に設定し、短い間隔では少し余裕を持たせるようにしています。この手順により、制限値が単なる勘ではなく、測定続く。.

展開計画とコミュニケーション

私は「ビッグバン」という名称をガバナーには決して導入しません。その手順は定評のあるものです：1) インベントリー アクティブなアカウントについて、負荷プロファイルに基づく大まかなクラスタリング。2) モニター専用 少なくとも1～2週間、週間の傾向を把握するため。3) クラスターごとの基本リミットの設定、および 段階的な導入 段階的に実施し、その都度KPI（エラー率、P95レイテンシ、中断率）を綿密に監視します。4) 微調整および例外事項の文書化。並行して、顧客に対し、「フェアシェア」という目標、帯域制限が発生する典型的な原因、および有効な最適化策について、積極的に情報を提供しています。透明性を高めることで、問い合わせを減らし、制限に対する理解と受容度を高めることができます。.

レプリケーション、バックアップ、および特別ユーザーの保護

システムに精通したユーザーなど レプリケーション- 或いは バックアップユーザー 予期せぬ速度低下が生じてはなりません。私はそのようなアカウントを明確に分類し、記録を残した上で、自動的な帯域制限の対象から除外しています。バックアップについては、ユーザー負荷に並行して影響が出ないよう、ストレージの「快適ゾーン」を下回る読み取り制限を設定しています。レプリケーションに関しては、キャッチアップ処理が本番環境の負荷を脅かさないよう注意を払っています。短い間隔の場合はやや余裕を持たせ、長い間隔の場合は保守的に設定することで、継続的なキャッチアップが恒久的なボトルネックにならないようにしています。重要なのは、 サービス- および顧客アカウントを、指標の一貫性を保つために。.

急激な過負荷時の緊急対応手順

制限を設けても目立った劣化が見られる場合は、修正を加えます プレイブック 対処法：1) dbtopでトップアカウントを特定し、その制限を一時的に厳格化する。2) 当該ユーザーの接続上限を減らし、スレッドプールの負荷を軽減する。3) 長時間実行中のクエリを可視化し、目立つクエリを優先的に最適化または一時停止する。 4) システム全体に負荷がかかっている場合は、プラットフォームを安定させるために、問題の原因となっているユーザーのLVE制限を一時的に引き下げる。5) 状況が落ち着いたら段階的に制限を元に戻し、根本原因（インデックス、キャッシュ、コード）を恒久的に解決する。今後の対応を迅速化できるよう、各措置の実施時刻と測定された効果をすべて記録しています。.

簡単にまとめると：実践可能な指針

私は、明確に区別された限界 CPU、READ、WRITEについては、リソースごとに影響が異なるためです。まずは保守的な設定から始め、モニター専用モードで効果を測定し、曲線が信頼できる傾向を示し始めたら、Abusenモードで限界値を設定します。長期的な間隔についてはより厳格に管理し、必要に応じて第2の保護段階が確実に作動するよう、グローバルなLVE制限を下回って運用します。接続数も注視し、アカウントあたり30セッションから開始し、ワークロードや時間帯に応じて調整します。技術的な制御と、アプリケーションの根本原因への対策とを組み合わせています。そうすることで、 データベース 同じサーバー上のあらゆるプロジェクトに対し、信頼性が高く、公平で、迅速な対応を実現します。.