Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
仮想化のチューニングと最適化ガイド
RHEL 上のホストシステムと仮想化ゲストでの KVM パフォーマンス機能の使用
概要
第1章 はじめに
1.1. 仮想化でパフォーマンスの最適化が重要な理由
1.2. KVM パフォーマンスアーキテクチャーの概要
- KVM を使用する場合、ゲストはホスト上で Linux プロセスとして実行されます。
- 仮想 CPU (vCPU) は通常のスレッドとして実装され、Linux スケジューラーで処理されます。
- ゲストは、カーネルから NUMA や Huge Page などの機能を自動的に継承しません。
- ホストのディスクおよびネットワーク I/O の設定は、仮想マシンのパフォーマンスに大きく影響します。
- ネットワークトラフィックは通常、ソフトウェアベースのブリッジを通過します。
- デバイスとそのモデルによっては、その特定のハードウェアのエミュレーションにより、オーバーヘッドが著しくなる可能性があります。
1.3. 仮想化のパフォーマンスの機能と改善
Red Hat Enterprise Linux 7 での仮想化パフォーマンスの向上
- 自動 NUMA バランシング
- 自動 NUMA バランシングにより、Red Hat Enterprise Linux 7 ゲストを手動で調整しなくても、NUMA ハードウェアシステムで実行されているアプリケーションのパフォーマンスが向上します。自動 NUMA バランシングは、スレッドまたはプロセスである可能性のあるタスクを、アクセスしているメモリーの近くに移動します。これにより、ゼロ設定で優れたパフォーマンスが可能になります。ただし、状況によっては、より正確なゲスト設定を提供したり、CPU やメモリーのアフィニティーをホストするようにゲストを設定したりすると、より良い結果が得られる場合があります。自動 NUMA バランシングの詳細については、「自動 NUMA バランシング」 を参照してください。
- VirtIO モデル
- virtio モデルを備えた仮想ハードウェアには、すべての特殊性を備えたハードウェアをエミュレートするオーバーヘッドはありません。VirtIO デバイスは、仮想化環境で使用するために特別に設計されているため、オーバーヘッドが低くなります。ただし、すべてのゲストオペレーティングシステムがそのようなモデルをサポートしているわけではありません。
- マルチキュー virtio-net
- パケットの送受信処理をゲストの使用可能な vCPU の数に合わせてスケーリングできるネットワークアプローチ。マルチキュー virtio-net の詳細については、「マルチキュー virtio-net」 を参照してください。
- ブリッジのゼロコピー送信
- ゼロコピー送信モードでは、スループットに影響を与えることなく、ゲストネットワークと外部ネットワーク間で大きなパケットを送信する際のホスト CPU オーバーヘッドが最大 15% 削減されます。ブリッジのゼロコピー送信は、Red Hat Enterprise Linux 7 仮想マシンで完全にサポートされていますが、デフォルトでは無効になっています。ゼロコピー送信の詳細については、「ブリッジのゼロコピー送信」 を参照してください。
- APIC 仮想化 (APICv)
- 新しい Intel プロセッサーは、Advanced Programmable Interrupt Controller (APICv) のハードウェア仮想化を提供します。APICv は、ゲストが APIC に直接アクセスできるようにすることで、仮想化された AMD64 および Intel 64 ゲストのパフォーマンスを向上させ、APIC によって引き起こされる割り込みレイテンシーと仮想マシンの終了数を大幅に削減します。この機能は、新しい Intel プロセッサーでデフォルトで使用され、I/O パフォーマンスを向上させます。
- EOI アクセラレーション
- 仮想 APIC 機能のない古いチップセットでの高帯域幅 I/O の割り込み終了アクセラレーション。
- マルチキュー virtio-scsi
- virtio-scsi ドライバーのマルチキューサポートによって提供されるストレージパフォーマンスとスケーラビリティーの向上。これにより、各仮想 CPU に別個のキューを持たせることが可能になります。また仮想 CPU は、その他の vCPU に影響を及ぼすことなく使用するために、割り込みできるようになります。マルチキュー virtio-scsi の詳細については、「マルチキュー virtio-scsi」 を参照してください。
- 準仮想化チケットロック
- 準仮想化チケットロック (pvticketlocks) は、オーバーサブスクライブされた CPU を搭載した Red Hat Enterprise Linux 7 ホストで実行されている Red Hat Enterprise Linux 7 ゲスト仮想マシンのパフォーマンスを向上させます。
- 準仮想化ページフォールト
- 準仮想化ページフォールトは、ホストによってスワップアウトされたページにアクセスしようとすると、ゲストにインジェクトされます。これにより、ホストメモリーがオーバーコミットされ、ゲストメモリーがスワップアウトされた場合の KVM ゲストのパフォーマンスが向上します。
- 準仮想化時間
vsyscallの最適化 - gettimeofday および clock_gettime システムコールは、
vsyscallメカニズムを介してユーザースペースで実行されます。以前は、これらのシステムコールを発行するには、システムをカーネルモードに切り替えてから、ユーザースペースに戻す必要がありました。これにより、一部のアプリケーションのパフォーマンスが大幅に向上します。
Red Hat Enterprise Linux の仮想化パフォーマンス機能
- CPU/カーネル
- NUMA - Non-Uniform Memory Access。NUMA の詳細については、9章NUMA を参照してください。
- CFS - Completely Fair Scheduler。最新のクラス重視のスケジューラー。
- RCU - Read Copy Update。共有スレッドデータの処理が改善されます。
- 最大 160 個の仮想 CPU (vCPU)。
- メモリー
- メモリーを大量に消費する環境向けのヒュージページやその他の最適化。詳しくは 8章メモリー を参照してください。
- ネットワーク
- vhost-net - 高速なカーネルベースの VirtIO ソリューション。
- SR-IOV - ネイティブに近いネットワークパフォーマンスレベル用。
- ブロック I/O
- AIO - 他の I/O 操作とオーバーラップするスレッドのサポート。
- MSI - PCI バスデバイスの割り込み生成。
- ディスク I/O スロットリング - ゲストディスク I/O 要求を制御して、ホストリソースの過剰使用を防ぎます。詳しくは 「ディスク I/O スロットリング」 を参照してください。
第2章 パフォーマンス監視ツール
2.1. perf kvm
# yum install perf
/proc/modules ファイルと /proc/kallsyms ファイルにアクセスできる必要があります。ファイルをホストに転送し、ファイルに関するレポートを実行する場合は、手順2.1「ゲストからホストへの /proc ファイルのコピー」 を参照してください。
手順2.1 ゲストからホストへの /proc ファイルのコピー
ゲストへのログインとファイルの保存
ゲストにログインし、/proc/modulesと/proc/kallsymsを一時的な場所/tmpに保存します。# cat /proc/modules > /tmp/modules # cat /proc/kallsyms > /tmp/kallsyms
ホストへの一時ファイルのコピー
ゲストからログオフしたら、次の scp コマンドの例を実行して、保存されたファイルをホストにコピーします。ホスト名と TCP ポートが異なる場合は、それらを置き換える必要があります。# scp root@GuestMachine:/tmp/kallsyms guest-kallsyms # scp root@GuestMachine:/tmp/modules guest-modules
これで、ホスト上のゲストからの 2 つのファイル (guest-kallsymsとguest-modules) が作成され、perf kvm で使用できるようになりました。perf kvm を使用したイベントの記録とレポート
前の手順で取得したファイルを使用して、ゲスト、ホスト、またはその両方のイベントの記録とレポートが可能になりました。次のコマンド例を実行します。# perf kvm --host --guest --guestkallsyms=guest-kallsyms \ --guestmodules=guest-modules record -a -o perf.data
注記コマンドで --host と --guest の両方が使用されている場合、出力はperf.data.kvmに保存されます。--host のみが使用されている場合、ファイルの名前はperf.data.hostになります。同様に、-guest のみが使用されている場合、ファイルの名前はperf.data.guestになります。Ctrl-C を押すと、記録が停止します。イベントのレポート
次のコマンド例は、記録プロセスによって取得されたファイルを使用し、出力を新しいファイルanalyzeにリダイレクトします。perf kvm --host --guest --guestmodules=guest-modules report -i perf.data.kvm \ --force > analyze
analyzeファイルのコンテンツを表示して、記録されたイベントを調べます。# cat analyze # Events: 7K cycles # # Overhead Command Shared Object Symbol # ........ ............ ................. ......................... # 95.06% vi vi [.] 0x48287 0.61% init [kernel.kallsyms] [k] intel_idle 0.36% vi libc-2.12.so [.] _wordcopy_fwd_aligned 0.32% vi libc-2.12.so [.] __strlen_sse42 0.14% swapper [kernel.kallsyms] [k] intel_idle 0.13% init [kernel.kallsyms] [k] uhci_irq 0.11% perf [kernel.kallsyms] [k] generic_exec_single 0.11% init [kernel.kallsyms] [k] tg_shares_up 0.10% qemu-kvm [kernel.kallsyms] [k] tg_shares_up [output truncated...]
2.2. 仮想パフォーマンス監視ユニット (vPMU)
arch_perfmon フラグを確認します。
# cat /proc/cpuinfo|grep arch_perfmoncpu mode を host-passthrough として指定します。
# virsh dumpxml guest_name |grep "cpu mode"
<cpu mode='host-passthrough'>2.3. Virtual Machine Manager でのパフォーマンスのモニターリング
2.3.1. Virtual Machine Manager でのパフォーマンス概要の表示
- Virtual Machine Manager のメインウィンドウで、表示する仮想マシンを強調表示します。
図2.1 表示する仮想マシンの選択

- 仮想マシンマネージャーのEdit メニューから、Virtual Machine Details を選択します。仮想マシンの詳細ウィンドウが開くと、コンソールが表示される場合があります。これが発生した場合は、View をクリックし、Details を選択します。デフォルトでは、Overview ウィンドウが最初に開きます。
- 左側のナビゲーションペインから Performance を選択します。Performance ビューには、CPU およびメモリーの使用量、ディスクおよびネットワークの入出力など、ゲストのパフォーマンスの概要が表示されます。
図2.2 ゲストのパフォーマンスの詳細の表示

2.3.2. パフォーマンスのモニターリング
- Edit メニューから、Preferences を選択します。Preferences ウィンドウが表示されます。
- Polling タブから、秒単位の時間または統計ポーリングオプションを指定します。
図2.3 パフォーマンスモニターリングの設定

2.3.3. ゲストの CPU 使用率の表示
- View メニューから Graph を選択し、Guest CPU Usage チェックボックスをオンにします。
- Virtual Machine Manager は、システム上のすべての仮想マシンの CPU 使用率グラフを表示します。
図2.4 ゲスト CPU 使用率グラフ

2.3.4. ホストの CPU 使用率の表示
- View メニューから Graph を選択し、Host CPU Usage チェックボックスをオンにします。
- Virtual Machine Manager は、システム上のホストの CPU 使用率グラフを表示します。
図2.5 ホストの CPU 使用率グラフ

2.3.5. ディスク I/O の表示
- ディスク I/O 統計情報の収集が有効になっていることを確認してください。これを行うには、Edit メニューから Preferences を選択し、Polling タブをクリックします。
- Disk I/O チェックボックスをオンにします。
図2.6 ディスク I/O の有効化

- ディスク I/O 表示を有効にするには、View メニューから Graph を選択し、Disk I/O チェックボックスをオンにします。選択します。
- Virtual Machine Manager は、システム上のすべての仮想マシンのディスク I/O のグラフを表示します。
図2.7 ディスク I/O の表示

2.3.6. ネットワーク I/O の表示
- ネットワーク I/O 統計情報の収集が有効になっていることを確認してください。これを行うには、Edit メニューから Preferences を選択し、Polling タブをクリックします。
- Network I/O チェックボックスをオンにします。
図2.8 ネットワーク I/O の有効化

- ネットワーク I/O 統計情報を表示するには、View メニューから Graph を選択し、Network I/O チェックボックスをオンにします。
- Virtual Machine Manager は、システム上のすべての仮想マシンのネットワーク I/O グラフを表示します。
図2.9 ネットワーク I/O の表示

2.3.7. メモリー使用量の表示
- メモリー使用量の統計情報の収集が有効になっていることを確認してください。これを行うには、Edit メニューから Preferences を選択し、Polling タブをクリックします。
- Poll Memory stats チェックボックスをオンにします。
図2.10 メモリー使用量の有効化

- メモリー使用量を表示するには、View メニューから Graph を選択し、Memory Usage チェックボックスをオンにします。
- Virtual Machine Manager は、システム上のすべての仮想マシンで使用されているメモリーの割合 (メガバイト単位) を一覧表示します。
図2.11 メモリー使用量の表示

第3章 virt-manager による仮想化パフォーマンスの最適化
3.1. オペレーティングシステムの詳細とデバイス
3.1.1. ゲスト仮想マシンの詳細の指定
図3.1 OS のタイプとバージョンの提供

3.1.2. 未使用デバイスの削除
図3.2 未使用デバイスの削除

3.2. CPU パフォーマンスのオプション
図3.3 CPU パフォーマンスのオプション

3.2.1. オプション: 使用可能な CPU
図3.4 CPU のオーバーコミット

3.2.2. オプション: CPU 設定
図3.5 CPU 設定オプション

3.2.3. オプション: CPU トポロジー
図3.6 CPU トポロジーのオプション

3.3. 仮想ディスクパフォーマンスのオプション
図3.7 仮想ディスクパフォーマンスのオプション

第4章 tuned と tuned-adm
virtual-guestvirtual-guestはthroughput-performanceプロファイルをベースにしており、仮想メモリーのスワップも減少します。virtual-guestプロファイルは、Red Hat Enterprise Linux 7 ゲスト仮想マシンを作成するときに自動的に選択されます。これは、仮想マシンに推奨されるプロファイルです。このプロファイルは Red Hat Enterprise Linux 6.3 以降で使用できますが、仮想マシンをインストールするときに手動で選択する必要があります。virtual-hostthroughput-performanceプロファイルに基づき、virtual-hostはダーティページのより積極的なライトバックも有効にします。このプロファイルは、KVM ホストと Red Hat Virtualization (RHV) ホストの両方を含む仮想化ホストに推奨されるプロファイルです。
tuned サービスが有効になります。
# tuned-adm list
Available profiles:
- balanced
- desktop
- latency-performance
- network-latency
- network-throughput
- powersave
- sap
- throughput-performance
- virtual-guest
- virtual-host
Current active profile: throughput-performancetuned-adm activetuned-adm profile profile_namevirtual-host プロファイルに切り替えるには、以下を実行します。
tuned-adm profile virtual-host# systemctl enable tuned# tuned-adm off# tuned-adm off; systemctl disable tuned第5章 ネットワーク
5.1. ネットワークチューニングのヒント
- 複数のネットワークを使用して、単一ネットワークでの輻輳を回避します。たとえば、管理、バックアップ、またはライブマイグレーション専用のネットワークを用意します。
- Red Hat は、同じネットワークセグメントで複数のインターフェイスを使用しないことをお勧めします。ただし、それが避けられない場合は、
arp_filterを使用して、ホストとゲストの両方で発生する可能性があり、マシンが複数のネットワークインターフェイスからの ARP 要求に応答することによって引き起こされる望ましくない状態である ARP Flux を防ぐことができます。この設定を永続化するには、echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter または/etc/sysctl.confを編集します。
5.2. Virtio と vhost_net
図5.1 Virtio および vhost_net アーキテクチャー

5.3. デバイスの割り当てと SR-IOV
図5.2 デバイスの割り当てと SR-IOV

5.4. ネットワークチューニング技術
5.4.1. ブリッジのゼロコピー送信
experimental_zcopytx カーネルモジュールパラメーターを 1 に設定します。詳細な手順については、Virtualization Deployment and Administration Guide を参照してください。
experimental_zcopytx を 0 に設定することで、ゼロコピー送信モードを無効にできます。
5.4.2. マルチキュー virtio-net
- トラフィックパケットが比較的大きい。
- ゲストが多くの接続で同時にアクティブになり、トラフィックがゲストとゲスト、ゲストとホスト、ゲストと外部システムの間に流れる。
- キューの数が vCPU の数と同じ。これは、マルチキューのサポートにより、特定のキューを特定の vCPU に対してプライベートにするために、RX 割り込みアフィニティーと TX キューの選択が最適化されるためです。
5.4.2.1. マルチキュー virtio-net の設定
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
<driver name='vhost' queues='N'/>
</interface>
# ethtool -L eth0 combined M5.5. ネットワークパケットのバッチ処理
# ethtool -C $tap rx-frames Ntun/tap rx バッチ処理を提供するには、次のようなスニペットをドメイン XML ファイルに追加します。
...
<devices>
<interface type='network'>
<source network='default'/>
<target dev='vnet0'/>
<coalesce>
<rx>
<frames max='7'/>
</rx>
</coalesce>
</interface>
</devices>
第6章 I/O スケジューリング
6.1. 仮想化ホストとして Red Hat Enterprise Linux を使用した I/O スケジューリング
deadline スケジューラーが理想的です。このスケジューラーは、ほぼすべてのワークロードで適切に機能します。
cfq スケジューラーを使用することが推奨されます。
6.2. 仮想化ゲストとして Red Hat Enterprise Linux を使用した I/O スケジューリング
- Red Hat Enterprise Linux のゲストは、多くの場合、
noopスケジューラーを使用することで大きなメリットが得られます。スケジューラーは、ハイパーバイザーに I/O を送信する前に、ゲストオペレーティングシステムからの小さな要求を大きな要求にマージします。これにより、ハイパーバイザーは I/O 要求をより効率的に処理できるようになり、ゲストの I/O パフォーマンスも大幅に向上します。 - ワークロード I/O とストレージデバイスがどのようにアタッチされているかによっては、
deadlineなどのスケジューラーがnoopよりも有益な場合があります。Red Hat は、パフォーマンステストを実行して、どのスケジューラーがパフォーマンスに最も影響を与えるかを確認することをお勧めします。 - iSCSI、SR-IOV、または物理デバイスパススルーによってアクセスされるストレージを使用するゲストは、
noopスケジューラーを使用しないでください。これらのメソッドでは、ホストが基盤となる物理デバイスへの I/O 要求を最適化することはできません。
6.2.1. Red Hat Enterprise Linux 7 の I/O スケジューラーの設定
deadline です。ただし、Red Hat Enterprise Linux 7 ゲストマシンでは、以下を実行して、スケジューラーを noop に変更すると便利な場合があります。
/etc/default/grubファイルで、GRUB_CMDLINE_LINUX行のelevator=deadline文字列をelevator=noopに変更します。elevator=文字列がない場合は、行の最後にelevator=noopを追加します。以下は、変更が成功した後の/etc/default/grubファイルを示しています。# cat /etc/default/grub [...] GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg00/lvroot rhgb quiet elevator=noop" [...]/boot/grub2/grub.cfgファイルを再構築します。- BIOS ベースのマシンの場合:
# grub2-mkconfig -o /boot/grub2/grub.cfg - UEFI ベースのマシンの場合:
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
第7章 ブロック I/O
7.1. ブロック I/O チューニング
<blkio> 要素で、ゲスト仮想マシンのブロック I/O パラメーターを手動で設定または表示できます。
<blkio> パラメーターを表示するには、以下を実行します。
# virsh blkiotune virtual_machine
<blkio> パラメーターを設定するには、virsh blkiotune コマンドを使用して、お使いの環境に応じてオプションの値を置き換えます。
# virsh blkiotune virtual_machine [--weight number] [--device-weights string] [--config] [--live] [--current]weight- 100 から 1000 までの範囲内の I/O の重み。デバイスの I/O ウェイトを上げると、I/O 帯域幅の優先度が高まるため、より多くのホストリソースが提供されます。同様に、デバイスのウェイトを下げると、ホストのリソースが少なくなります。
device-weights/path/to/device,weight,/path/to/device,weight の形式で、1 つ以上のデバイス/重みのペアをリストする単一の文字列。デバイスごとのリストからそのデバイスを削除するには、各重みが 100 - 1000 の範囲内であるか、値が 0 である必要があります。文字列にリストされているデバイスのみが変更されます。他のデバイスのデバイスごとの重みは変更されません。config- 次回の起動時に変更を有効にするには、
--configオプションを追加します。 live--liveオプションを追加して、実行中の仮想マシンに変更を適用します。注記--liveオプションでは、ハイパーバイザーがこのアクションをサポートする必要があります。すべてのハイパーバイザーが、最大メモリー制限のライブ変更を許可するわけではありません。current--currentオプションを追加して、現在の仮想マシンに変更を適用します。
/dev/sda デバイスの重みを 500 に変更します。
# virsh blkiotune liftbrul --device-weights /dev/sda, 500
7.2. キャッシュ
表7.1 キャッシングオプション
| キャッシングオプション | 説明 |
|---|---|
| Cache=none | ゲストからの I/O はホストにキャッシュされませんが、ライトバックディスクキャッシュに保持される場合があります。このオプションは、I/O 要件が大きいゲストに使用します。このオプションは一般的に最善の選択であり、移行をサポートする唯一のオプションです。 |
| Cache=writethrough | ゲストからの I/O はホストにキャッシュされますが、物理メディアに書き込まれます。このモードは遅く、スケーリングの問題が発生しやすくなります。I/O 要件が小さい少数のゲストに最適です。移行が不要な、ライトバックキャッシュをサポートしていないゲスト (Red Hat Enterprise Linux 5.5 以前など) に推奨されます。 |
| Cache=writeback | ゲストからの I/O はホストにキャッシュされます。 |
| Cache=directsync | writethrough に似ていますが、ゲストからの I/O はホストページのキャッシュを回避します。 |
| Cache=unsafe | ホストはすべてのディスク I/O をキャッシュする可能性があり、ゲストからの同期要求は無視されます。 |
| Cache=default | キャッシュモードが指定されていない場合は、システムのデフォルト設定が選択されます。 |
driver タグ内の cache 設定を編集してキャッシュオプションを指定します。たとえば、キャッシュを writeback に設定するには、以下を実行します。
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='writeback'/>
7.3. I/O モード
表7.2 IO モードオプション
| IO モードオプション | 説明 |
|---|---|
| IO=native | Red Hat Virtualization (RHV) 環境のデフォルト。このモードは、ダイレクト I/O オプションを備えたカーネル非同期 I/O を指します。 |
| IO=threads | デフォルトは、ホストユーザーモードベースのスレッドです。 |
| IO=default | Red Hat Enterprise Linux 7 のデフォルトはスレッドモードです。 |
driver タグ内の io 設定を編集し、native、threads、または default を指定します。たとえば、I/O モードを threads に設定するには、以下を実行します。
<disk type='file' device='disk'>
<driver name='qemu' type='raw' io='threads'/>
7.4. ブロック I/O チューニング技術
7.4.1. ディスク I/O スロットリング
# virsh blkdeviotune virtual_machine device --parameter limit
<target dev='name'/>) またはソースファイル (<source file='name'/>) を指定します。ディスクデバイス名のリストについては、virsh domblklist コマンドを使用してください。
total-bytes-sec- 総スループットの上限 (バイト毎秒単位)。
read-bytes-sec- 読み取りスループットの上限 (バイト毎秒単位)。
write-bytes-sec- 書き込みスループットの上限 (バイト毎秒単位)。
total-iops-sec- 1 秒あたりの I/O 操作の制限合計。
read-iops-sec- 1 秒あたりの読み取り I/O 操作数の制限。
write-iops-sec- 1 秒あたりの書き込み I/O 操作数の制限。
virtual_machine の vda を 1 秒あたり 1000 の I/O 操作と、1 秒スループットあたり 50 MB にスロットリングするには、次のコマンドを実行します。
# virsh blkdeviotune virtual_machine vda --total-iops-sec 1000 --total-bytes-sec 52428800
7.4.2. マルチキュー virtio-scsi
7.4.2.1. マルチキュー virtio-scsi の設定
<controller type='scsi' index='0' model='virtio-scsi'>
<driver queues='N' />
</controller>
第8章 メモリー
8.1. メモリーチューニングのヒント
- ゲストが使用するよりも多くのリソースをゲストに割り当てないでください。
- 可能であれば、ゲストを単一の NUMA ノードに割り当てます。ただし、その NUMA ノードでリソースが十分であることを条件とします。NUMA の使用の詳細については、9章NUMA を参照してください。
8.2. 仮想マシンでのメモリーチューニング
8.2.1. メモリーモニターリングツール
- top
- vmstat
- numastat
- /proc/
8.2.2. virsh によるメモリーチューニング
<memtune> 要素を使用すると、管理者はゲスト仮想マシンのメモリー設定を手動で設定できます。<memtune> を省略した場合、仮想マシンは、仮想マシンの作成時に割り当てられた方法に基づいてメモリーを使用します。
<memtune> 要素でメモリーパラメーターを表示または設定するには、virsh memtune コマンドで、実際の環境に応じて値を置き換えてください。
# virsh memtune virtual_machine --parameter size
hard_limit- 仮想マシンが使用できる最大メモリー。単位はキビバイト (1024 バイトのブロック) です。警告この制限を低く設定しすぎると、仮想マシンがカーネルによって強制終了される可能性があります。
soft_limit- メモリー競合中に強制するメモリー制限。単位はキビバイト (1024 バイトのブロック) です。
swap_hard_limit- 仮想マシンが使用できる最大メモリーとスワップ。単位はキビバイト (1024 バイトのブロック) です。
swap_hard_limit値は、hard_limit値よりも大きくなければなりません。 min_guarantee- 仮想マシンに保証される最小メモリー割り当て。単位はキビバイト (1024 バイトのブロック) です。
<memoryBacking> 要素には、仮想メモリーページがホストページによってどのようにバックアップされるかに影響を与えるいくつかの要素が含まれる場合があります。
locked を設定すると、ホストはゲストに属するメモリーページをスワップアウトできなくなります。ゲスト XML に以下を追加して、ホストのメモリー内の仮想メモリーページをロックします。
<memoryBacking>
<locked/>
</memoryBacking>
locked を設定する場合は、<memtune> 要素でhard_limitを、ゲストに設定された最大メモリーと プロセス自体で消費されるメモリーに設定する必要があります。
nosharepages を設定すると、ホストはゲスト間で使用されているのと同じメモリーをマージできなくなります。ハイパーバイザーがゲストの共有ページを無効にするように指示するには、ゲストの XML に以下を追加します。
<memoryBacking>
<nosharepages/>
</memoryBacking>
8.2.3. Huge Page と Transparent Huge Page
8.2.3.1. Transparent Huge Page の設定
# cat /sys/kernel/mm/transparent_hugepage/enabled
# echo always > /sys/kernel/mm/transparent_hugepage/enabled
これにより、/sys/kernel/mm/transparent_hugepage/enabled が always に設定されます。
# echo never > /sys/kernel/mm/transparent_hugepage/enabled8.2.3.2. 静的 Huge Page の設定
<memoryBacking>
<hugepages/>
</memoryBacking>
cat /proc/sys/vm/nr_hugepages
手順8.1 Huge Page の設定
- 現在の Huge Page の値を表示します。
# cat /proc/meminfo | grep Huge AnonHugePages: 2048 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB - Huge Page は 2 MB 単位で設定されます。Huge Page の数を 25000 に設定するには、次のコマンドを使用します。
echo 25000 > /proc/sys/vm/nr_hugepages注記設定を永続的にするには、ゲストマシンの/etc/sysctl.confファイルに次の行を追加します。X は意図した Huge Page の数です。# echo 'vm.nr_hugepages = X' >> /etc/sysctl.conf # sysctl -p
その後、ゲストの/etc/grub2.cfgファイルの/kernel行の末尾にtransparent_hugepage=neverを追加します。 - Huge Page をマウントします。
# mount -t hugetlbfs hugetlbfs /dev/hugepages - 仮想マシンの XML 設定の memoryBacking セクションに次の行を追加します。
<hugepages> <page size='1' unit='GiB'/> </hugepages>
- libvirtd を再起動します。
#systemctl restart libvirtd - 仮想マシンを起動します。
#virsh start virtual_machine - 仮想マシンがすでに実行中の場合は再起動します。
#virsh reset virtual_machine
/proc/meminfoの変更を確認します。# cat /proc/meminfo | grep Huge AnonHugePages: 0 kB HugePages_Total: 25000 HugePages_Free: 23425 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
8.2.3.3. 起動時またはランタイムにおけるゲスト用 1 GB Huge Page の有効化
手順8.2 起動時の 1 GB Huge Page の割り当て
- 起動時にさまざまなサイズの Huge Page を割り当てるには、次のコマンドを使用して Huge Page の数を指定します。この例では、4 つの 1 GB の Huge Page と 1024 の 2 MB の Huge Page を割り当てます。
'default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024'
このコマンドラインを変更して、起動時に割り当てる Huge Page の別の数を指定します。注記次の 2 つの手順も、起動時に 1 GB の Huge Page を初めて割り当てるときに完了する必要があります。 - 2 MB と 1 GB の Huge Page をホストにマウントします。
# mkdir /dev/hugepages1G # mount -t hugetlbfs -o pagesize=1G none /dev/hugepages1G # mkdir /dev/hugepages2M # mount -t hugetlbfs -o pagesize=2M none /dev/hugepages2M
- 仮想マシンの XML 設定の memoryBacking セクションに次の行を追加します。
<hugepages> <page size='1' unit='GiB'/> </hugepages>
- libvirtd を再起動して、ゲストで 1 GB の Huge Page を使用できるようにします。
# systemctl restart libvirtd
手順8.3 ランタイムの 1 GB Huge Page の割り当て
- ランタイムでさまざまなサイズの Huge Page を割り当てるには、次のコマンドを使用して、Huge Page の数、それらを割り当てる NUMA ノード、および Huge Page サイズの値を置き換えます。
# echo 4 > /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages # echo 1024 > /sys/devices/system/node/node3/hugepages/hugepages-2048kB/nr_hugepages
このコマンドの例では、node1から 4 つの 1 GB の Huge Page を割り当て、node3から 1024 の 2 MB の Huge Page を割り当てます。これらの Huge Page 設定は、ホストシステムの空きメモリーの量に応じて、上記のコマンドでいつでも変更できます。注記次の 2 つの手順も、ランタイムで 1 GB の Huge Page を初めて割り当てるときに完了する必要があります。 - 2 MB と 1 GB の Huge Page をホストにマウントします。
# mkdir /dev/hugepages1G # mount -t hugetlbfs -o pagesize=1G none /dev/hugepages1G # mkdir /dev/hugepages2M # mount -t hugetlbfs -o pagesize=2M none /dev/hugepages2M
- 仮想マシンの XML 設定の memoryBacking セクションに次の行を追加します。
<hugepages> <page size='1' unit='GiB'/> </hugepages>
- libvirtd を再起動して、ゲストで 1 GB の Huge Page を使用できるようにします。
# systemctl restart libvirtd
8.3. Kernel Same-page Merging (KSM)
qemu-kvm プロセスからのみメモリーを継承します。ゲストが実行されると、ゲストが同じオペレーティングシステムまたはアプリケーションを実行しているときに、ゲストオペレーティングシステムイメージのコンテンツを共有できます。KSM を使用すると、KVM はこれらの同一のゲストメモリー領域を共有するように要求できます。
/sys/kernel/mm/ksm/merge_across_nodes を 0 に変更して、NUMA ノード間でページがマージされないようにします。これは、virsh node-memory-tune --shm-merge-across-nodes 0 コマンドを使用して実行できます。カーネルメモリーが計算した統計情報は、ノード間での大量のマージ後にはそれぞれの間で相反する場合があります。そのため、KSM デーモンが大量のメモリーをマージすると、numad が混乱する可能性があります。システムに未使用のメモリーが大量にあると、KSM デーモンをオフにして無効にすることでパフォーマンスが高まる場合があります。NUMA の詳細については 9章NUMA を参照してください。
ksmサービス は、KSM カーネルスレッドを開始および停止します。ksmtunedサービス は、ksmサービスを制御およびチューニングし、same-page マージを動的に管理します。ksmtunedは、ksmサービスを開始し、メモリー共有が不要な場合はksmサービスを停止します。新しいゲストが作成または破棄された場合、ksmtunedにretuneパラメーターを実行するように指示する必要があります。
8.3.1. KSM サービス
ksmサービスは qemu-kvm パッケージに含まれています。ksmサービスが開始されていない場合、Kernel same-page merging (KSM) は 2000 ページのみを共有します。このデフォルト値を使用すると、メモリー節約の利点が限定されます。ksmサービスが開始されると、KSM はホストシステムのメインメモリーの最大半分を共有します。ksmサービスを開始して、KSM がより多くのメモリーを共有できるようにしてください。
# systemctl start ksm
Starting ksm: [ OK ]ksm サービスは、デフォルトの起動シーケンスに追加できます。systemctl コマンドを使用して ksm サービスを永続化します。
# systemctl enable ksm
8.3.2. KSM チューニングサービス
ksmtuned サービスは、ksm をループおよびチューニングすることにより、kernel same-page merging (KSM) の設定を微調整します。さらに、ゲスト仮想マシンが作成または破棄されると、ksmtuned サービスに libvirt から通知されます。ksmtuned サービスにはオプションがありません。
# systemctl start ksmtuned
Starting ksmtuned: [ OK ]ksmtuned サービスは、チューニング機能を手動で実行するように ksmtuned に指示する retune パラメーターを使用してチューニングできます。
/etc/ksmtuned.conf ファイルは、ksmtuned サービスの設定ファイルです。以下のファイル出力は、デフォルトの ksmtuned.conf ファイルです。
# Configuration file for ksmtuned. # How long ksmtuned should sleep between tuning adjustments # KSM_MONITOR_INTERVAL=60 # Millisecond sleep between ksm scans for 16Gb server. # Smaller servers sleep more, bigger sleep less. # KSM_SLEEP_MSEC=10 # KSM_NPAGES_BOOST - is added to the `npages` value, when `free memory` is less than `thres`. # KSM_NPAGES_BOOST=300 # KSM_NPAGES_DECAY - is the value given is subtracted to the `npages` value, when `free memory` is greater than `thres`. # KSM_NPAGES_DECAY=-50 # KSM_NPAGES_MIN - is the lower limit for the `npages` value. # KSM_NPAGES_MIN=64 # KSM_NPAGES_MAX - is the upper limit for the `npages` value. # KSM_NPAGES_MAX=1250 # KSM_THRES_COEF - is the RAM percentage to be calculated in parameter `thres`. # KSM_THRES_COEF=20 # KSM_THRES_CONST - If this is a low memory system, and the `thres` value is less than `KSM_THRES_CONST`, then reset `thres` value to `KSM_THRES_CONST` value. # KSM_THRES_CONST=2048 # uncomment the following to enable ksmtuned debug information # LOGFILE=/var/log/ksmtuned # DEBUG=1
/etc/ksmtuned.conf ファイル内で、npages は、ksmd デーモンが非アクティブになる前に ksm がスキャンするページ数を設定します。この値は、/sys/kernel/mm/ksm/pages_to_scan ファイルでも設定されます。
KSM_THRES_CONST の値は、ksm をアクティブ化するためのしきい値として使用される使用可能なメモリーの量を表します。次のいずれかが発生した場合、ksmd がアクティブになります。
- 空きメモリーの量が、
KSM_THRES_CONSTで設定されたしきい値を下回る。 - コミットされたメモリーの量としきい値
KSM_THRES_CONSTが、メモリーの合計量を超えている。
8.3.3. KSM 変数とモニターリング
/sys/kernel/mm/ksm/ ディレクトリーに保存します。このディレクトリー内のファイルは、カーネルによって更新される、KSM の使用状況と統計の正確な記録です。
/etc/ksmtuned.conf ファイルの設定可能な変数でもあります。
/sys/kernel/mm/ksm/ 内のファイル:
- full_scans
- フルスキャンが実行されます。
- merge_across_nodes
- 異なる NUMA ノードからのページをマージできるかどうか。
- pages_shared
- 共有されたページの総数。
- pages_sharing
- 現在共有されているページ。
- pages_to_scan
- スキャンされていないページ。
- pages_unshared
- 共有されなくなったページ。
- pages_volatile
- 揮発性ページの数。
- run
- KSM プロセスが実行されているかどうか。
- sleep_millisecs
- スリープのミリ秒。
# virsh node-memory-tune --shm-pages-to-scan number
DEBUG=1 行が /etc/ksmtuned.conf ファイルに追加された場合、KSM チューニングアクティビティーは /var/log/ksmtuned ログファイルに保存されます。ログファイルの場所は、LOGFILE パラメーターを使用して変更できます。ログファイルの場所を変更することはお勧めできません。SELinux 設定の特別な設定が必要になる場合があります。
8.3.4. KSM の非アクティブ化
ksmtuned および ksm サービスを停止することで非アクティブ化できます。ただし、このアクションは再起動後に維持されません。KSM を非アクティブ化するには、ターミナルで root として以下を実行します。
# systemctl stop ksmtuned Stopping ksmtuned: [ OK ] # systemctl stop ksm Stopping ksm: [ OK ]
ksmtuned と ksm を停止すると、KSM が非アクティブ化されますが、このアクションは再起動後に維持されません。KSM を永続的に非アクティブ化するには、systemctl コマンドを使用します。
# systemctl disable ksm
# systemctl disable ksmtuned# echo 2 >/sys/kernel/mm/ksm/run
khugepaged デーモンは KVM ゲストの物理メモリーに Transparent Huge Page を再構築できます。# echo 0 >/sys/kernel/mm/ksm/run を使用すると、KSM が停止しますが、以前に作成されたすべての KSM ページの共有は解除されません (これは # systemctl stop ksmtuned コマンドと同じです)。
第9章 NUMA
9.1. NUMA メモリーの割り当てポリシー
Strict- Strict ポリシーとは、ターゲットノードにメモリーを割り当てることができない場合に割り当てが失敗することを意味します。メモリーモード属性を定義せずに NUMA ノードセットリストを指定すると、デフォルトで
strictモードになります。 Interleave- メモリーページは、ノードセットで指定されたノード間で割り当てられますが、ラウンドロビン方式で割り当てられます。
Preferred- メモリーは、単一の優先メモリーノードから割り当てられます。十分なメモリーが利用できない場合は、他のノードからメモリーを割り当てることができます。
<memory mode> 要素の値として設定します。
<numatune>
<memory mode='preferred' nodeset='0'>
</numatune>
strict モードでメモリーがオーバーコミットされ、ゲストに十分なスワップスペースがない場合、カーネルは一部のゲストプロセスを強制終了して、追加のメモリーを取得します。Red Hat は、この状況を防ぐために、preferred 割り当てを使用し、単一のノードセット (たとえば nodeset = '0') を指定することをお勧めします。
9.2. 自動 NUMA バランシング
- プロセスメモリーの定期的な NUMA マッピング解除
- NUMA ヒント障害
- Migrate-on-Fault (MoF) - メモリーを、それを使用するプログラムが実行される場所に移動します
- task_numa_placement - メモリーを実行中のプログラムの近くに移動します
9.2.1. 自動 NUMA バランシングの設定
- # numactl --hardware shows multiple nodes
- # cat /proc/sys/kernel/numa_balancing shows
1
# echo 0 > /proc/sys/kernel/numa_balancing# echo 1 > /proc/sys/kernel/numa_balancing9.3. libvirt NUMA チューニング
# numastat -c qemu-kvm
Per-node process memory usage (in MBs)
PID Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
--------------- ------ ------ ------ ------ ------ ------ ------ ------ -----
51722 (qemu-kvm) 68 16 357 6936 2 3 147 598 8128
51747 (qemu-kvm) 245 11 5 18 5172 2532 1 92 8076
53736 (qemu-kvm) 62 432 1661 506 4851 136 22 445 8116
53773 (qemu-kvm) 1393 3 1 2 12 0 0 6702 8114
--------------- ------ ------ ------ ------ ------ ------ ------ ------ -----
Total 1769 463 2024 7462 10037 2672 169 7837 32434
# numastat -c qemu-kvm
Per-node process memory usage (in MBs)
PID Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
--------------- ------ ------ ------ ------ ------ ------ ------ ------ -----
51747 (qemu-kvm) 0 0 7 0 8072 0 1 0 8080
53736 (qemu-kvm) 0 0 7 0 0 0 8113 0 8120
53773 (qemu-kvm) 0 0 7 0 0 0 1 8110 8118
59065 (qemu-kvm) 0 0 8050 0 0 0 0 0 8051
--------------- ------ ------ ------ ------ ------ ------ ------ ------ -----
Total 0 0 8072 0 8072 0 8114 8110 32368
-c で numastat を実行すると、コンパクトな出力が得られます。-m オプションを追加すると、ノードごとにシステム全体のメモリー情報が出力に追加されます。詳細は、numastat の man ページを参照してください。
9.3.1. ホスト NUMA ノードごとのメモリーのモニターリング
nodestats.py スクリプトを使用して、ホスト上の各 NUMA ノードの合計メモリーと空きメモリーを報告できます。このスクリプトは、実行中のドメインごとに、特定のホストノードに厳密にバインドされているメモリーの量も報告します。以下に例を示します。
# /usr/share/doc/libvirt-python-2.0.0/examples/nodestats.py
NUMA stats
NUMA nodes: 0 1 2 3
MemTotal: 3950 3967 3937 3943
MemFree: 66 56 42 41
Domain 'rhel7-0':
Overall memory: 1536 MiB
Domain 'rhel7-1':
Overall memory: 2048 MiB
Domain 'rhel6':
Overall memory: 1024 MiB nodes 0-1
Node 0: 1024 MiB nodes 0-1
Domain 'rhel7-2':
Overall memory: 4096 MiB nodes 0-3
Node 0: 1024 MiB nodes 0
Node 1: 1024 MiB nodes 1
Node 2: 1024 MiB nodes 2
Node 3: 1024 MiB nodes 3MemTotal)。ほぼすべてのメモリーが各ドメインで消費されます ( MemFree)。4 つのドメイン (仮想マシン) が実行されています。ドメイン 'rhel7-0' には 1.5 GB のメモリーがあり、特定のホスト NUMA ノードに固定されていません。ただし、ドメイン 'rhel7-2' には、4 GB のメモリーと 4 つの NUMA ノードがあり、ホストノードに 1:1 で固定されています。
nodestats.py スクリプトを作成します。スクリプトの例は、/usr/share/doc/libvirt-python-version/examples/nodestats.py の libvirt-python パッケージファイルにあります。スクリプトへの特定のパスは、rpm -ql libvirt-python コマンドを使用して表示できます。
9.3.2. NUMA vCPU のピニング
<vcpu cpuset='0-7'>8</vcpu>
<cputune>
<vcpupin vcpu='0' cpuset='0'/>
<vcpupin vcpu='1' cpuset='1'/>
<vcpupin vcpu='2' cpuset='2'/>
<vcpupin vcpu='3' cpuset='3'/>
<vcpupin vcpu='4' cpuset='4'/>
<vcpupin vcpu='5' cpuset='5'/>
<vcpupin vcpu='6' cpuset='6'/>
<vcpupin vcpu='7' cpuset='7'/>
</cputune>
<vcpupin> がないことを示しています。したがって、vCPU5 は、親タグ <vcpu> で指定されているように、物理 CPU 0 - 7 にピニングされます。
<vcpu cpuset='0-7'>8</vcpu>
<cputune>
<vcpupin vcpu='0' cpuset='0'/>
<vcpupin vcpu='1' cpuset='1'/>
<vcpupin vcpu='2' cpuset='2'/>
<vcpupin vcpu='3' cpuset='3'/>
<vcpupin vcpu='4' cpuset='4'/>
<vcpupin vcpu='6' cpuset='6'/>
<vcpupin vcpu='7' cpuset='7'/>
</cputune>
<vcpupin>、<numatune>、および <emulatorpin> を一緒に設定する必要があります。<numatune> タグの詳細については、「ドメインプロセス」 を参照してください。<emulatorpin> タグの詳細については、「emulatorpin の使用」 を参照してください。
9.3.3. ドメインプロセス
<numatune> タグ内で設定する方法の例は、以下の XML 設定を参照してください。
<numatune>
<memory mode='strict' placement='auto'/>
</numatune>
<numatune>
<memory mode='strict' nodeset='0,2-3'/>
</numatune>
<vcpu> タグ内で設定する方法の例は、以下の XML 設定を参照してください。
<vcpu placement='auto'>8</vcpu>
<vcpu placement='static' cpuset='0-10,ˆ5'>8</vcpu>
<vcpu> と <numatune> に使用する配置モードには、暗黙的な継承ルールがあります。
<numatune>の配置モードは、デフォルトでは<vcpu>と同じ配置モードに設定され、<nodeset>が指定されている場合は static です。- 同様に、
<vcpu>の配置モードは、デフォルトでは<numatune>と同じ配置モードに設定され、<cpuset>が指定されている場合は static です。
<vcpu placement='auto' current='8'>32</vcpu>
9.3.4. ドメイン vCPU スレッド
<cputune> タグ内の各 vcpu スレッドのピニングポリシーを設定します。
<cputune>
<vcpupin vcpu="0" cpuset="1-4,ˆ2"/>
<vcpupin vcpu="1" cpuset="0,1"/>
<vcpupin vcpu="2" cpuset="2,3"/>
<vcpupin vcpu="3" cpuset="0,4"/>
</cputune>
<cputune> の詳細については、次の URL を参照してください: http://libvirt.org/formatdomain.html#elementsCPUTuning
4 available nodes (0-3) Node 0: CPUs 0 4, size 4000 MiB Node 1: CPUs 1 5, size 3999 MiB Node 2: CPUs 2 6, size 4001 MiB Node 3: CPUs 0 4, size 4005 MiB
<cputune> <vcpupin vcpu="0" cpuset="1"/> <vcpupin vcpu="1" cpuset="5"/> <vcpupin vcpu="2" cpuset="2"/> <vcpupin vcpu="3" cpuset="6"/> </cputune> <numatune> <memory mode="strict" nodeset="1-2"/> </numatune> <cpu> <numa> <cell id="0" cpus="0-1" memory="3" unit="GiB"/> <cell id="1" cpus="2-3" memory="3" unit="GiB"/> </numa> </cpu>
9.3.5. Cache Allocation Technology によるパフォーマンスの向上
cachetune タグ内で設定する方法の例は、以下の XML 設定を参照してください。
<domain>
<cputune>
<cachetune vcpus='0-1'>
<cache id='0' level='3' type='code' size='3' unit='MiB'/>
<cache id='0' level='3' type='data' size='3' unit='MiB'/>
</cachetune>
</cputune>
</domain><cachetune> 要素を設定できます。
libvirt ドキュメント の cachetune を参照してください。
9.3.6. emulatorpin の使用
<cputune> 内の <emulatorpin> タグを使用することです。
<emulatorpin> タグは、エミュレーター (vCPU を含まないドメインのサブセット) がピニングされるホスト物理 CPU を指定します。<emulatorpin> タグは、エミュレータースレッドプロセスに正確なアフィニティーを設定する方法を提供します。その結果、vhost スレッドは物理 CPU とメモリーの同じサブセットで実行されるため、キャッシュ局所性を活用できます。たとえば、以下のようになります。
<cputune>
<emulatorpin cpuset="1-3"/>
</cputune>
<emulatorpin> の手動チューニングの必要性は低下します。自動 NUMA バランシングの詳細については、「自動 NUMA バランシング」 を参照してください。
9.3.7. virsh を使用した vCPU ピニングのチューニング
% virsh vcpupin rhel7 1 2
% virsh vcpupin rhel7
9.3.8. virsh を使用したドメインプロセス CPU ピニングのチューニング
emulatorpin オプションは、各ドメインプロセスに関連付けられているスレッドに CPU アフィニティー設定を適用します。完全にピニングするには、各ゲストに virsh vcpupin (前に示したとおり) および virsh emulatorpin の両方を使用する必要があります。以下に例を示します。
% virsh emulatorpin rhel7 3-4
9.3.9. virsh を使用したドメインプロセスメモリーポリシーのチューニング
% virsh numatune rhel7 --nodeset 0-10
9.3.10. ゲスト NUMA トポロジー
<cpu> タグ内の <numa> タグを使用して指定できます。次の例を参照してください。値は適宜、置き換えます。
<cpu>
...
<numa>
<cell cpus='0-3' memory='512000'/>
<cell cpus='4-7' memory='512000'/>
</numa>
...
</cpu>
<cell> 要素は、NUMA セルまたは NUMA ノードを指定します。cpus はノードの一部である CPU または CPU 範囲を指定し、memory はノードメモリーをキビバイト (1024 バイトのブロック) で指定します。各セルまたはノードには、0 から始まる昇順で cellid または nodeid が割り当てられます。
9.3.11. PCI デバイスの NUMA ノードの局所性
/sys/devices/pci*/*/numa_node の sysfs ファイルに表示されます。これらの設定を確認する 1 つの方法は、lstopo ツールを使用して sysfs データを報告することです。
# lstopo-no-graphics
Machine (126GB)
NUMANode L#0 (P#0 63GB)
Socket L#0 + L3 L#0 (20MB)
L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#2)
L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#4)
L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#6)
L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4 + PU L#4 (P#8)
L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5 + PU L#5 (P#10)
L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6 + PU L#6 (P#12)
L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7 + PU L#7 (P#14)
HostBridge L#0
PCIBridge
PCI 8086:1521
Net L#0 "em1"
PCI 8086:1521
Net L#1 "em2"
PCI 8086:1521
Net L#2 "em3"
PCI 8086:1521
Net L#3 "em4"
PCIBridge
PCI 1000:005b
Block L#4 "sda"
Block L#5 "sdb"
Block L#6 "sdc"
Block L#7 "sdd"
PCIBridge
PCI 8086:154d
Net L#8 "p3p1"
PCI 8086:154d
Net L#9 "p3p2"
PCIBridge
PCIBridge
PCIBridge
PCIBridge
PCI 102b:0534
GPU L#10 "card0"
GPU L#11 "controlD64"
PCI 8086:1d02
NUMANode L#1 (P#1 63GB)
Socket L#1 + L3 L#1 (20MB)
L2 L#8 (256KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8 + PU L#8 (P#1)
L2 L#9 (256KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9 + PU L#9 (P#3)
L2 L#10 (256KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10 + PU L#10 (P#5)
L2 L#11 (256KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11 + PU L#11 (P#7)
L2 L#12 (256KB) + L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12 + PU L#12 (P#9)
L2 L#13 (256KB) + L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13 + PU L#13 (P#11)
L2 L#14 (256KB) + L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14 + PU L#14 (P#13)
L2 L#15 (256KB) + L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15 + PU L#15 (P#15)
HostBridge L#8
PCIBridge
PCI 1924:0903
Net L#12 "p1p1"
PCI 1924:0903
Net L#13 "p1p2"
PCIBridge
PCI 15b3:1003
Net L#14 "ib0"
Net L#15 "ib1"
OpenFabrics L#16 "mlx4_0"
- NIC
em*とディスクsd*は、NUMA ノード 0 とコア 0、2、4、6、8、10、12、14 に接続されている。 - NIC
p1*とib*は、NUMA ノード 1 およびコア 1、3、5、7、9、11、13、15 に接続されている。
9.4. NUMA-Aware Kernel SamePage Merging (KSM)
sysfs /sys/kernel/mm/ksm/merge_across_nodes パラメーターを使用して、異なる NUMA ノード間でのページのマージを制御します。デフォルトでは、すべてのノードのページをマージできます。このパラメーターがゼロに設定されている場合、同じノードのページのみがマージされます。
<memoryBacking>
<nosharepages/>
</memoryBacking>
<memoryBacking> 要素を使用したメモリー設定のチューニングの詳細については、「virsh によるメモリーチューニング」 を参照してください。
付録A 更新履歴
| 改訂履歴 | |||
|---|---|---|---|
| 改訂 1.0-35 | Thus May 23 2019 | Jiri Herrmann | |
| |||
| 改訂 1.0-34 | Tue Oct 25 2018 | Jiri Herrmann | |
| |||
| 改訂 1.0-32 | Tue Aug 14 2018 | Jiri Herrmann | |
| |||
| 改訂 1.0-31 | Wed Apr 4 2018 | Jiri Herrmann | |
| |||
| 改訂 1.0-27 | Mon Jul 27 2017 | Jiri Herrmann | |
| |||
| 改訂 1.0-24 | Mon Oct 17 2016 | Jiri Herrmann | |
| |||
| 改訂 1.0-22 | Mon Dec 21 2015 | Laura Novich | |
| |||
| 改訂 1.0-19 | Thu Oct 08 2015 | Jiri Herrmann | |
| |||