クラウドサーバーの自主規制

1つの段落のニュース:パフォーマンスの制限を自問する機会が現れました。 CPU、RAM、および発信トラフィックは制限されています。

次のようになります。

cap_forced



早く気に入らない? ゆっくりできます!



コントロールパネルに、リソース消費の制限を設定する機能を提供しました。 すべての仮想マシンのこれらのデフォルト設定は「制限しない」に設定されており、これは以前の動作と変わりません。



これらの設定の範囲は(「遊び回る」ことに加えて)新しいソフトウェアの研究またはアプリケーションの起動であり、その妥当性は疑います。 プログラムがそれを完了するために100500の操作を実行する必要がある場合、それを実行することを理解する必要があります。 1秒あたり500操作の速度、1秒あたり100操作の速度。 問題は、彼女がこれをどれだけ早く行うかだけです。



トラフィックについても同様です。 サーバーが100500 MBのファイルを提供することを決定した場合、サーバーはそれを提供します。 900 Mb / sの速度、または1 M​​b / sの速度で-時間のみが異なります。



...突然の「間違った」負荷に対する人の反応時間を含む。 フリークアウトプログラムがCPUの800%を消費し、インターネットチャネルを天井に差し込むことと、「天井」がCPUの20%および数メガビットである場合、それは1つです。



言い換えれば、設定は、誰かが便利になることを願っています。



実際には制限はどのように見えますか?



CPU



(技術部分:早口言葉):Xenのクレジットベースのスケジューリングの上限パラメーターを使用すると、ドメインの実行をスケジュールできる制限を指定できます。



同じですが、次の構成があります。ハイパーバイザーを使用すると、仮想マシンを実行中の時間で制限できます。 仮想マシンが制限の期限が切れる前にすべてを行うために「管理」されている場合、残りの時間をハイパーバイザーに「与える」ため、制限は認識されません。 仮想マシンが制限に達すると、ハイパーバイザーは仮想マシンから制御を強制的に「取得」し、次の間隔の開始まであきらめません。 間隔自体は短く、10ミリ秒です。



仮想マシンの観点から見ると、この制限はスチール時間のように見えます。 仮想マシンがプロセッサを使用した実際の時間に応じて支払いを行うため、スチール時間は支払われません。



どのように見えますか?



これは、cpuburn実行中の10%の設定制限でtopにロードされるシステムの外観です(お金を燃やすためのユーティリティ):

cpu_cap

CPUの90%を占めているようです。 実際には-9%。 別のパーセントはシステムプロセスによって占有されています。 見てみると、古い(右上)は80%です。



これは同じですが、htopの観点からです:

cpu_cap_htop



そして上に:

cpu_cap_atop



この意味での注意は誰よりも賢いです-サーバーがプロセッサ時間で「資金不足」であることを明確に示しています。



スチールに関する注意:CPUの1%(つまり、8コアで最大8%)は、無制限の仮想マシンでは正常です-dom0へのデータ転送時にIOとネットワークアクティビティの両方のリクエストを処理すると、仮想マシンが次のような状態にブロックされますスチール時に、この値が10〜15%を超えると、仮想マシンのプロセッサ時間が不足します。 Xen'e-およびrackspace、およびAmazonのすべてのホスティングに適用されます。



それ自体では、パラメーターによりCPUの最大1%を制限できますが、10%でもマシンはいくらか思慮深くなります。そのため、コントロールパネルを5%に制限しました。そうしないと、ユーザーはダウンロードの完了を待たないリスクを負います。



発信トラフィック



(技術的な新機能)ネットバックのqos_ratelimit_kpbsパラメーターを使用すると、ドメインから転送されるデータの速度を制限できます。



インターフェイスの4 Mbpsの制限は次のとおりです。

レート制限



人の説明:ヘンの準仮想化ネットワークデバイスは、2つの半分で構成されています。 1つは仮想マシンにあるネットフロントです。 他の半分-ネットバック-はdom0にあります。 仮想マシン宛てのトラフィックが到着すると、ドメイン間でページを転送するためのかなりトリッキーなメカニズム(ゼロコピーとも呼ばれます)を介して仮想マシンに送信されます。 逆のプロセスも同様です。



このプロセス(xenのすべてのものと同様)が協調的であることが重要です。つまり、一方で「欲求」を送信し、他方で「受け入れる」欲求を同時に送信する必要があります。 受信側がデータを受信したくない場合、リングバッファ(ドメイン間の共有メモリに配置され、コンポーネントの動作を調整するために使用される特別なデータ構造)がオーバーフローします。 「循環」であるため、送信者にはオプションがありません。受信者がデータを読み取るのを待つ(およびリングバッファ内のポインタを移動する)か、送信するデータに関するデータを上書きします。



したがって、受信者はデータ受信の速度を制限することができます。「遅い読み取り」で十分です。



限界 これは、limitオプションが設定されている場合にnetbackが行うこと(dom0のドライバーの半分)とまったく同じです。 仮想マシンのネットワークアダプターからのデータの読み取りが遅くなります。



問題が発生します:着信トラフィックはどうですか?



ここでの状況はまったく異なります。トラフィックはすでに送信されています。 ドロップするか、転送することができます。 送信する時間がない場合、トラフィックは破棄されます(そうしないと、トラフィックが蓄積し始め、RAMが詰まります)。 速度によって制限することはできません。超過分を破棄することによってのみ可能です。 そして、これにはネットワークの品質の著しい低下が伴います。



All Articles