CloudLinux

CloudLinux LVEを解説:CPU、メモリ、エントリープロセスの制限

混雑するホスティングアカウントと過負荷のサーバーの違いを理解し、リソース履歴で遅いページや制限関連のエラーを調べましょう。

読了まで約 8 分
CloudLinux LVEを解説:CPU、メモリ、エントリープロセスの制限 - ACE Peripherals

CloudLinux LVEは、共有サーバー上でホスティングアカウントが消費できるリソースを制限します。 マシン全体に余力があっても、サイトがアカウントの上限に達する場合があります。上限の引き上げ、ハードウェアの交換、インターネット回線への原因の決めつけを行う前に、該当するリソースと発生時刻を特定してください。

小規模なウェブサイトでも、一日の大半は快適なのに、商品インポート、バックアップ、アクセスの急増時に遅くなることがあります。「サーバーのRAMには十分な余裕がある」だけでは判断できません。ホスティングアカウントに独自のCPU、メモリ、I/O、プロセスの上限が設定されている可能性があります。

LVEの役割

LVEはLightweight Virtual Environmentの略です。アカウントのプロセスに対してリソースを制御し、1つのアカウントが共有マシンを使い尽くしにくくします。互換性のあるCloudLinuxホスティングスタックの一部であり、すべてのNASで有効にできる設定ではありません。

物理サーバーを共用設備のある建物、各アカウントを割り当てを持つ入居者と考えてみてください。建物全体が満杯になる前に、ある入居者が割り当てを使い切る場合があります。それだけで割り当てが不適切とは言えません。想定外にリソースを消費するタスクが使っている可能性もあります。

経路全体を確認

アカウントの制限とホストの制限は異なります

物理サーバーに余力が残っていても、アカウントのリソース制御の上限に達する場合があります。

01 ホスティングアカウント

アプリケーション要求 + ジョブアカウントのCPU / メモリ / I/Oエントリーとプロセスの制限同じ時間帯で照合

短時間のリソース超過は、対応するログとリソース履歴で確認します。1枚のエラーページだけでは診断できません。

02 物理ホスト

ホストされる全アカウントサーバーのリソース + サービス事業者の容量とポリシー2つの調査を分ける

アカウントの割り当てを増やしても、利用不能な外部API、アプリケーションの不具合、あらゆる共有サービスの問題を解決できるわけではありません。

これはリソースの階層を説明したものです。具体的な指標、エラー時の動作、管理画面は、ホスティングスタックと設定によって異なります。

リソース制限は、ファイルシステムの分離、マルウェア対策、バックアップとも異なります。これらは別々の制御で、それぞれ設定と復旧の要件があります。制限を設けても悪意のあるコードは削除されず、昨日のデータベースも得られません。

エラーページだけでなくリソースを確認

リソース 確認する質問 有用な観察事項
CPU / SPEED 処理がCPU時間を待っていますか? 同じ時刻のアカウント履歴と高負荷のプロセス
物理メモリ アカウントで使用可能なメモリが不足しましたか? メモリの超過記録とアプリケーションエラー
I/OとIOPS ストレージの転送量または処理回数が制限されていますか? 大容量転送と多数の小さな処理の違い
エントリープロセス アカウントが該当するエントリー上限に達していますか? 超過履歴、ワークロード、ウェブサーバーの実装
プロセス数 アカウントのアクティブなプロセスが多すぎますか? プロセス数と、それらを作成したタスク

SPEED設定の100%は、プロセッサーの1コアを基準とする値であり、ホストの全コアを使えるという保証ではありません。エントリープロセスは1日の訪問者数とは異なり、単純に開いているブラウザー接続すべてを指すわけでもありません。ウェブサーバースタックによって実装が異なるため、事業者がどのスタックとカウンターを説明しているか確認してください。

障害が発生した時間帯を調べる

影響を受けたURL、おおよその時刻とタイムゾーン、表示されたエラー、実行中だったタスクから確認します。その時間帯のアカウントのリソース履歴を、アプリケーションログとアクセスログに照合してください。数時間後の静かなグラフでは、障害時に何が起きたかは分かりません。

その時間帯に重なるジョブを列挙します。定期バックアップ、検索インデックス作成、サムネイル生成、インポート、cronタスク、クローラー、アプリケーション更新などです。毎晩同じ時刻に繰り返し失敗するなら、サーバーを変更する前にスケジュールを調べる十分な理由があります。

アプリケーション自体の証拠を確認してください。遅いデータベースクエリ、外部APIの応答待ち、キャッシュされていない動的ページによって、処理が長くアクティブなままになることがあります。その結果、同時処理が増え、他の制限にも負荷がかかります。最初に有効な対策は、上位のホスティングプランではなく、アプリケーションやスケジュールの変更かもしれません。

原因を隠す対処を避ける

すべての上限を繰り返し引き上げると、どの制限が重要かを把握する機会を失い、他のアカウントに重い負荷を及ぼす可能性があります。サーバー全体の再起動は無関係の利用者も中断させ、有用な一時的証拠を失わせる場合があります。

ホスティング管理者と、範囲を限定した変更を選んでください。負荷の高いタスクを1つ改善する、重なるジョブを分散する、適切なアカウント割り当てを調整する、常に大きな負荷を適したプラットフォームへ移すなどです。その後、同じワークロードで確認し、1回のページ読み込み成功だけでなく、エラーとリソース超過も見直してください。

適用されるCloudLinux/Apache構成では、508応答がエントリープロセスの上限に関連する場合があります。メモリやプロセスの逼迫もアプリケーション障害を招きます。HTTPステータスだけでは完全な診断になりません。アカウント履歴とログで結論を裏付ける必要があります。

容量と復旧を一緒に計画する

企業が自社のワークロードをホストする場合は、アプリケーション、対応OS、メモリ、ストレージ、バックアップ時間帯、必要な復旧内容を明確にします。高速なストレージは実際のストレージボトルネックには役立ちますが、ホスティング事業者のアカウント単位の上限を回避することはできません。

この NAS、SAN、クラウドの計画ガイド は、より広い視点でプラットフォームを選ぶ方法を説明しています。対応する設計であればNASは適切なバックアップ先になりますが、自動的にCloudLinuxホスティングサーバーになるわけではありません。互換性や容量に不確実な点が残る場合は、 概念実証 を実際のワークロードに絞って実施してください。

調査につながるサポート情報を送る

対象アカウント、時間帯、URLまたはタスク、エラー文、関連するリソース履歴を提供してください。最近の変更と再現の可否も含めます。認証情報と不要な個人情報を取り除いたログを、承認されたサポート窓口で共有してください。

実務上の答え: アカウントの割り当て、アプリケーション、物理ホストのどこが混雑していたかを特定し、その境界に対処します。無関係な目立つ仕様を理由に大型のマシンを買うより、根拠のある判断になります。

よくある質問

サーバーのRAMに余裕があれば、アカウントのメモリ制限は否定できますか?

いいえ。ホストに余力があっても、CloudLinuxホスティングアカウントに独自のメモリ割り当てがある場合があります。

SPEED 100%はサーバー全体を意味しますか?

文書化されたSPEED設定では、サーバーの全コアではなく1コアに相当します。

エントリープロセスは1日の訪問者数と同じですか?

いいえ。リソース制御の仕組みを表すもので、具体的な動作はウェブサーバーの実装によって異なります。

508エラーは、より大型のサーバーが必要な証拠ですか?

いいえ。同じ時間帯のリソース超過記録とログを集めてください。原因はアカウントの割り当て、遅いタスク、アプリケーションの動作かもしれません。

高速なNASでLVEの上限をなくせますか?

いいえ。高速なストレージ機器でも、ホスティングアカウントに設定された割り当ては変更できません。

最初に何を変更すべきですか?

負荷の高いタスクや重複するスケジュールなど、証拠が示す原因を変更します。無関係な上限を引き上げる前に、管理者と結果を確認してください。

コメント (0)

まだコメントはありません。

コメントを投稿

コメントは確認後に公開されます。

テクノロジーを、深く。

テクノロジーを、もっと明確に。

役立つテクノロジーの知識をメールでお届けします。