- numadの利用（2ソケット以上のハードウェアを利用する場合）
- 複数ソケットのサーバはNUMA構成なので、できるだけ他ノードへのアクセスを減らしてやるとよい。CPU使用率が高くなるとたまたまちょっとヒマになったCPUにマイグレーションする可能性があがるためnuma nodeにVMを割りあててやりたい。
- 従来はベンチマークなどでvCPUのpinningなどが使われていたが、人間が指定するのではダイナミックに変化する状況に対応できないためあまり実用的で はなかった。numadはワークロードを見て、メモリとCPUの割り当てをnuma nodeに寄せる作業を自動的におこなってくれる。
- 起動直後に即座に影響がないのでちょっと気持ちわるい
- CPUのオーバーコミットをする場合、Xeon 7500/6500 + RHEL 6.2以降の利用(Pause-Loop Exiting対応)
- あたらしい世代だとどのCPUが対応してるんだろう……?
- https://github.com/qemu/qemu/blob/master/scripts/kvm/vmxcap を実行するとVMXの機能一覧をだしてくれるので、今つかっているマシンがPLE対応かどうか判定できる
- 仮想化環境でCPUのオーバーコミットをする場合、あるvCPUがロックを掴んだまま実行を停止し、他のvCPUではそのロックを待つためスピンロックしているケースが発生する。
- PLEはスピンロックのように見えるタイトなループを検出すると仮想マシンを停止してハイパーバイザに制御をもどす。同一VMの別スレッドにスケジュールすることでロック開放を待つためだけに多量のCPU時間を消費することを防ぐことができる。
- VMwareが従来複数vCPUをもつVMについて、全vCPUを同時にスケジュールするようにしていたのはおそらくこの問題を回避するためではないかしら(予想)。
- KVMはLinuxのスケジューラそのままなので各CPUは基本的に独立してスケジュールされるのでこの仕組みは大変よくきく。
- メモリはオーバーコミットしない
- メモリをオーバーコミットするとろくなことがありません。なので要るだけ積みあげます。安いし。
- ホストでのswapの発生によるVMから全く制御できない遅延
- 複数台ある場合の性能のブレ
- 特にゲストOSがlinuxの場合、メモリはあるだけ使おうとする。本来だとキャッシュとしての有効活用になるキャッシュを積極的に使う戦略が、メモリオーバーコミット環境下ではswapを多発させる原因になってしまう
- qemuのためにこれに加えてVM数x1GBくらい追加メモリを用意する(200から500MBくらいでいい気もしますが余裕をもって1GB)
- メモリは足りてるはずなのでKSMは停止する
- (optional) hugetlbfsの利用
- どうせVMに割りあてたメモリをswapさせないしさせたくない
- 事前に計画できるならtransparent huge pageより低コスト
- 結論: とにかくちょっと余るくらいメモリ積んどくといいよ
- NICはSR-IOVか物理的に分けてmacvtapでつなげる。bridgeを共有しない。
- ソフトウェアbridgeのコストは馬鹿にならない。ネットワークのレイテンシ増加とホスト側でのCPU消費の増大に直接繋がる
- SR-IOV対応NICはブリッジ機能もオンボードで提供していることがある
- パフォーマンスだけ考えれば、macvtapで繋げずにPCI passthroughで接続してもよい。だがその場合VMをマイグレーションできなくなるので注意が必要。
- ブロックデバイスのバックエンドにファイルシステムやLVMはつかわず、個別にLUNを切る。
- ファイルシステムのジャーナル処理が、ゲスト側とホスト側で2重になるのはほぼ利点がないがコストは高い。
