エンタープライズのXen Cloud Platform [3]
第三部。 前の部分： First 、 second 。
このトピックでは：メモリ管理と仮想マシンプロセッサ。
XCPがメモリでどのように機能するかを理解するには、Xenがメモリでどのように機能するかを理解する必要があります。 OpenVZとは異なり、Xenは常に排他的に使用するためにメモリを仮想マシン（より正確にはドメイン）に割り当てます。 ドメインメモリはドメインメモリであり、それ以上のものではありません。 オーバーセル、共有ページ、ハイパーバイザースワップはありません（もちろん、仮想マシンはスワップできます）。 4GBの場合、ゲストマシン間で約3.5GBを分割できます（512はdom0に移動します）。 それらをどのように共有するかはあなたの自由です。 ただし、使用可能なメモリより多くのメモリをマシンに割り当てることはできません。 いや ポイント。
しかし、実際に割り当てられたメモリの管理では、すべてが非常に優れています。 Xen 3.4では、メモリ管理メカニズム（xenballoon）は、かなり複雑な脳と脳の認識に基づいていますが、ハイパーバイザーの観点からは単純です。ドメインとハイパーバイザーの間でメモリページが転送されます。 送信とは、送信メモリが小さくなり、受信メモリが多くなることを意味します。 このメカニズムはxenballoonだけでなく、多くのドライバー（コピーを作成しないために、単にデータページを相互に転送する）を使用しますが、xenballoonのみがそのようなボリュームでそれらを乱用します。 バルーン自体は、その名前のとおりに機能します。ドメイン内で「膨張」し、占有された場所をハイパーバイザーに与えます。 ドメインに記憶が与えられると、ボールは吹き飛ばされます。
メモリ管理は無料ではありません。それ自体にビジネス費用のためのドメインメモリが少しかかります。 最悪の場合、これは約5％で、メモリが多いほどパーセンテージは小さくなります（16GBのメモリに対して、値は約1％に低下します）。
実行中のマシンにメモリを追加することと、実行中のマシンからメモリを削除することの2つのメモリ管理シナリオがあります。 削除すると、すべてが簡単になります-xenballoonはハイパーバイザーにページを提供します。 追加はより複雑です-カーネルは実際にアドレス空間を拡張できません（Xen 3.4メモリではホットプラグはまだサポートされていません）。したがって、このスキームはわずかに異なる方法で実装されます：ドメインを作成すると、一部のページはドメイン専用としてマークされ、すぐにハイパーバイザーに返送されます（つまり、ボールは事前に膨らんでいると見なされます）、適切なタイミングで、ハイパーバイザーはページをドメインに戻します。
このモデルにより、仮想メモリを拡張できる理論上の上限があります（ドメインの作成時、つまり仮想マシンの起動時に指定されます）。 これはオーバーヘッドの量に影響し、メモリの下限を人為的に制限します（16GBの場合は約512MB、2GBの場合は128MBと思われます）。 したがって、ドメインの起動時に設定される2つの境界
と
を取得します。 ユーザーがmemory_static_minを任意に低くすることができるという事実にもかかわらず、メモリの量は最大値から計算された特定の値を下回ることはありません。 これは、xenballloon.cコードに直接エンコードされており、OOMキラーを即座に保護するのに役立ちます（そのため、カーネルサービスデータに十分なメモリと機能する最小限のソフトウェアセットがあります）。 一部の場所では、バーをあまりにも積極的に上げます（特に2〜4GBの天井領域）。しかし、一般に、値はかなり妥当です。
これらの制限に加えて、さらに2つの（人工の）量、memory_dynamic_maxとmemory_dynamic_minが導入されています。 これらの値は、メモリを調整し、その場で変更できる境界を定義します（つまり、これは単なる管理上の慣習です）。 ターゲット値（memory_target）-必要なメモリ量もあります。 ほとんどの場合、メモリの量は必要に応じて作成されます（つまり、memory = memory_target）が、ターゲットリクエストを実行できない場合、これらの値は異なる場合があります。
仮想マシンのメモリ容量を調整するには、手動と自動の2つの方法があります。 手動でターゲットを指定された値に設定します。 自動は境界（最大/最小）を設定し、XCPに各ドメインのメモリサイズを調整する機能を提供します。
メモリ規制はDynamic Memory Controlと呼ばれ、プール内の各ホストで実行されるスクイズされたデーモンです（偶然のことですが、Debian Squeezeとは関係ありません）。 このデーモンは、使用可能な最大メモリを新しいドメインに割り当てます（ただし、dynamic-max以下）。ハイパーバイザーがメモリを必要とする場合（たとえば、新しい仮想マシンを起動するため）、すべてのマシンを圧縮します（dynamic-min以上）。 squeezedが必要な量のメモリを解放できなかった場合、ホストは新しい仮想マシンの起動を拒否します（どこから開始するかを正確に指定せずに
コマンドを
起動を実行すると、マシンは動作する場所で起動し、「ここから開始」と表示された場合、エラーが発生します）起動時）。
もちろん、使用可能な範囲内で動的な最小/最大値を変更できます。 値を変更する場合、変更の可能性はチェックされず、メモリ= 512Mb、動的最小= 2GiB、ターゲット= 4GiB、動的最大= 8GiBのマシンを取得できます。 （再起動時に、条件が満たされない場合、マシンは起動しません）。
いずれにせよ、メモリについては、変更のたびに式がチェックされます：
Xenは、プロセッサの動的な接続/切断をサポートしています。 （そして、はい、コメントからの質問に答えます-4つ以上のコアが存在する可能性があります。個人的には1つの仮想マシンから16コアを見ました。プロセッサの数は制限されていません）。 デフォルトでは、すべてのマシンは1つのプロセッサで作成されています;マルチプロセッシングを有効にするには、それらをオフにする必要があります。 動作を決定する3つの値があります。
Xenは非常に不正行為をしていると言わざるを得ず、外出先でプロセッサを接続することはできません。 実際、VCPUs-maxプロセッサは仮想マシンに含まれており、そのうちの一部のみがマークされています。 したがって、プロセッサの接続/切断は、OSの観点からはホットプラグではなく、単に「有効化/無効化」されます。 ただし、プロセス計画に含まれるプロセッサの数を変更しても、ゲストシステムのタスクの複雑さは軽減されません。 一部のプログラムは、プロセッサの数を変更することから激怒します（最も特徴的なのは、プロセッサのペアが接続されると、常にそこにあると仮定し始めますが、ハイパーバイザーはそれらを「盗んだ」）。 ほとんどのプログラムは気にしません-プロセッサの数を考慮しないためです。 「接続されているがオフになっている」プロセッサにはわずかなペナルティがあります-カーネルはまだそれらについて知っており、有効なコアの数ではなく、VCPU-maxコアの数によってメモリを予約します。
物理プロセッサよりも多くの仮想プロセッサが存在する可能性がありますが、これによりマシンで遅延が発生します（静かなコード実行の代わりに、ハイパーバイザーはプロセッサ間でコンテキストを常に切り替えます）。
通常、プロセッサは仮想マシンよりも少ないため、プロセッサ時間の競合があり、XenはOSカーネルがプロセスに関連して行うのと同じ方法で仮想マシンを計画しています。 現在、3つのスケジューラがあります（外出先で変更可能）-正直、リアルタイム、実験的です。 率直に言って、私は深く見ていませんでした、デフォルトの「正直な」ものはほとんどのタスクに十分です。
相互間では、仮想マシンにプロセッサ制限と相対的な優先順位を設定できます。
制限は、各プロセッサの最大許容マシン時間の割合を設定する上限値の形式で設定されます（各コアの上限は、2つのコアの上限= 75％がコンピュータ時間の150％であり、一部のドキュメントでは、上限は総消費量であると述べています）マシン、つまりcap = 150、cap = 330など-これは当てはまりません）。 cap = 10はマシン時間の10％を与え、強力なXeonを非常に不幸なP2（またはP1）に変えます。これは特にブート段階で深刻です。 原則として、上限を25％未満に下げることは価値がありません。なぜなら、マシンはコンソール内でも鈍化し始める可能性があるからです（bashの競争が広がりやすいため）。
2番目のメカニズムはより興味深い-これは相対的な優先順位です。 ハイパー仮想オウム（体重）で設定されます。 より長い仮想オウムを持つその仮想マシンは、より多くのマシン時間を取得します。
関係は厳密です-重量= 20のマシンは、重量= 10のマシンの少なくとも2倍のマシン時間を受け取ります（このマシン時間を消費したい場合、「優先」マシンがアイドル状態であれば、優先度の低いマシンは必要なだけ食べることができます）。 これらの数値は、数万に簡単にスケーリングできます（つまり、重量= 20,000および重量= 1のマシンが存在する場合があります。この場合、2番目は実際にはアイドル優先度で動作します）。
重要：残念ながら、すべての優先順位は、ドメインが停止している場合にのみ変更できます。
ギブレットを掘るのが特に繊細な愛好家の場合、特定のコアを仮想マシンに割り当て（いわゆるVCPUピン接続）、一部のプロセッサ機能（VPCU機能）をマスク（無効化）することができます。
を使用して、仮想マシンの実際の状況を確認できます。
このトピックでは：メモリ管理と仮想マシンプロセッサ。
記憶
XCPがメモリでどのように機能するかを理解するには、Xenがメモリでどのように機能するかを理解する必要があります。 OpenVZとは異なり、Xenは常に排他的に使用するためにメモリを仮想マシン（より正確にはドメイン）に割り当てます。 ドメインメモリはドメインメモリであり、それ以上のものではありません。 オーバーセル、共有ページ、ハイパーバイザースワップはありません（もちろん、仮想マシンはスワップできます）。 4GBの場合、ゲストマシン間で約3.5GBを分割できます（512はdom0に移動します）。 それらをどのように共有するかはあなたの自由です。 ただし、使用可能なメモリより多くのメモリをマシンに割り当てることはできません。 いや ポイント。
しかし、実際に割り当てられたメモリの管理では、すべてが非常に優れています。 Xen 3.4では、メモリ管理メカニズム（xenballoon）は、かなり複雑な脳と脳の認識に基づいていますが、ハイパーバイザーの観点からは単純です。ドメインとハイパーバイザーの間でメモリページが転送されます。 送信とは、送信メモリが小さくなり、受信メモリが多くなることを意味します。 このメカニズムはxenballoonだけでなく、多くのドライバー（コピーを作成しないために、単にデータページを相互に転送する）を使用しますが、xenballoonのみがそのようなボリュームでそれらを乱用します。 バルーン自体は、その名前のとおりに機能します。ドメイン内で「膨張」し、占有された場所をハイパーバイザーに与えます。 ドメインに記憶が与えられると、ボールは吹き飛ばされます。
メモリ管理は無料ではありません。それ自体にビジネス費用のためのドメインメモリが少しかかります。 最悪の場合、これは約5％で、メモリが多いほどパーセンテージは小さくなります（16GBのメモリに対して、値は約1％に低下します）。
実行中のマシンにメモリを追加することと、実行中のマシンからメモリを削除することの2つのメモリ管理シナリオがあります。 削除すると、すべてが簡単になります-xenballoonはハイパーバイザーにページを提供します。 追加はより複雑です-カーネルは実際にアドレス空間を拡張できません（Xen 3.4メモリではホットプラグはまだサポートされていません）。したがって、このスキームはわずかに異なる方法で実装されます：ドメインを作成すると、一部のページはドメイン専用としてマークされ、すぐにハイパーバイザーに返送されます（つまり、ボールは事前に膨らんでいると見なされます）、適切なタイミングで、ハイパーバイザーはページをドメインに戻します。
このモデルにより、仮想メモリを拡張できる理論上の上限があります（ドメインの作成時、つまり仮想マシンの起動時に指定されます）。 これはオーバーヘッドの量に影響し、メモリの下限を人為的に制限します（16GBの場合は約512MB、2GBの場合は128MBと思われます）。 したがって、ドメインの起動時に設定される2つの境界
memory_static_min
と
memory_static_max
を取得します。 ユーザーがmemory_static_minを任意に低くすることができるという事実にもかかわらず、メモリの量は最大値から計算された特定の値を下回ることはありません。 これは、xenballloon.cコードに直接エンコードされており、OOMキラーを即座に保護するのに役立ちます（そのため、カーネルサービスデータに十分なメモリと機能する最小限のソフトウェアセットがあります）。 一部の場所では、バーをあまりにも積極的に上げます（特に2〜4GBの天井領域）。しかし、一般に、値はかなり妥当です。
これらの制限に加えて、さらに2つの（人工の）量、memory_dynamic_maxとmemory_dynamic_minが導入されています。 これらの値は、メモリを調整し、その場で変更できる境界を定義します（つまり、これは単なる管理上の慣習です）。 ターゲット値（memory_target）-必要なメモリ量もあります。 ほとんどの場合、メモリの量は必要に応じて作成されます（つまり、memory = memory_target）が、ターゲットリクエストを実行できない場合、これらの値は異なる場合があります。
仮想マシンのメモリ容量を調整するには、手動と自動の2つの方法があります。 手動でターゲットを指定された値に設定します。 自動は境界（最大/最小）を設定し、XCPに各ドメインのメモリサイズを調整する機能を提供します。
メモリ規制はDynamic Memory Controlと呼ばれ、プール内の各ホストで実行されるスクイズされたデーモンです（偶然のことですが、Debian Squeezeとは関係ありません）。 このデーモンは、使用可能な最大メモリを新しいドメインに割り当てます（ただし、dynamic-max以下）。ハイパーバイザーがメモリを必要とする場合（たとえば、新しい仮想マシンを起動するため）、すべてのマシンを圧縮します（dynamic-min以上）。 squeezedが必要な量のメモリを解放できなかった場合、ホストは新しい仮想マシンの起動を拒否します（どこから開始するかを正確に指定せずに
xe vm-start
コマンドを
xe vm-start
起動を実行すると、マシンは動作する場所で起動し、「ここから開始」と表示された場合、エラーが発生します）起動時）。
もちろん、使用可能な範囲内で動的な最小/最大値を変更できます。 値を変更する場合、変更の可能性はチェックされず、メモリ= 512Mb、動的最小= 2GiB、ターゲット= 4GiB、動的最大= 8GiBのマシンを取得できます。 （再起動時に、条件が満たされない場合、マシンは起動しません）。
いずれにせよ、メモリについては、変更のたびに式がチェックされます：
static-min ≤ dynamic_min ≤ target ≤ dynamic_max ≤ static-max
プロセッサー（s）
Xenは、プロセッサの動的な接続/切断をサポートしています。 （そして、はい、コメントからの質問に答えます-4つ以上のコアが存在する可能性があります。個人的には1つの仮想マシンから16コアを見ました。プロセッサの数は制限されていません）。 デフォルトでは、すべてのマシンは1つのプロセッサで作成されています;マルチプロセッシングを有効にするには、それらをオフにする必要があります。 動作を決定する3つの値があります。
- VCPUs-max-ドメインのプロセッサーの最大数（ドメインの作成時、つまり仮想マシンの電源投入時に設定）。
- VCPUs-number-現在のプロセッサー数
- VCPUs-at-startup-マシンの電源を入れたときのプロセッサー数（ドメインの作成）
Xenは非常に不正行為をしていると言わざるを得ず、外出先でプロセッサを接続することはできません。 実際、VCPUs-maxプロセッサは仮想マシンに含まれており、そのうちの一部のみがマークされています。 したがって、プロセッサの接続/切断は、OSの観点からはホットプラグではなく、単に「有効化/無効化」されます。 ただし、プロセス計画に含まれるプロセッサの数を変更しても、ゲストシステムのタスクの複雑さは軽減されません。 一部のプログラムは、プロセッサの数を変更することから激怒します（最も特徴的なのは、プロセッサのペアが接続されると、常にそこにあると仮定し始めますが、ハイパーバイザーはそれらを「盗んだ」）。 ほとんどのプログラムは気にしません-プロセッサの数を考慮しないためです。 「接続されているがオフになっている」プロセッサにはわずかなペナルティがあります-カーネルはまだそれらについて知っており、有効なコアの数ではなく、VCPU-maxコアの数によってメモリを予約します。
物理プロセッサよりも多くの仮想プロセッサが存在する可能性がありますが、これによりマシンで遅延が発生します（静かなコード実行の代わりに、ハイパーバイザーはプロセッサ間でコンテキストを常に切り替えます）。
通常、プロセッサは仮想マシンよりも少ないため、プロセッサ時間の競合があり、XenはOSカーネルがプロセスに関連して行うのと同じ方法で仮想マシンを計画しています。 現在、3つのスケジューラがあります（外出先で変更可能）-正直、リアルタイム、実験的です。 率直に言って、私は深く見ていませんでした、デフォルトの「正直な」ものはほとんどのタスクに十分です。
相互間では、仮想マシンにプロセッサ制限と相対的な優先順位を設定できます。
制限は、各プロセッサの最大許容マシン時間の割合を設定する上限値の形式で設定されます（各コアの上限は、2つのコアの上限= 75％がコンピュータ時間の150％であり、一部のドキュメントでは、上限は総消費量であると述べています）マシン、つまりcap = 150、cap = 330など-これは当てはまりません）。 cap = 10はマシン時間の10％を与え、強力なXeonを非常に不幸なP2（またはP1）に変えます。これは特にブート段階で深刻です。 原則として、上限を25％未満に下げることは価値がありません。なぜなら、マシンはコンソール内でも鈍化し始める可能性があるからです（bashの競争が広がりやすいため）。
2番目のメカニズムはより興味深い-これは相対的な優先順位です。 ハイパー仮想オウム（体重）で設定されます。 より長い仮想オウムを持つその仮想マシンは、より多くのマシン時間を取得します。
関係は厳密です-重量= 20のマシンは、重量= 10のマシンの少なくとも2倍のマシン時間を受け取ります（このマシン時間を消費したい場合、「優先」マシンがアイドル状態であれば、優先度の低いマシンは必要なだけ食べることができます）。 これらの数値は、数万に簡単にスケーリングできます（つまり、重量= 20,000および重量= 1のマシンが存在する場合があります。この場合、2番目は実際にはアイドル優先度で動作します）。
重要：残念ながら、すべての優先順位は、ドメインが停止している場合にのみ変更できます。
ギブレットを掘るのが特に繊細な愛好家の場合、特定のコアを仮想マシンに割り当て（いわゆるVCPUピン接続）、一部のプロセッサ機能（VPCU機能）をマスク（無効化）することができます。
xentop
を使用して、仮想マシンの実際の状況を確認できます。
All Articles